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PREFACE 


The purpose of this manual is to provide the user with an introduction to, and 
instructions for using, the GCOS Environment Simulator. The simulator, together with 


other Multics Facilities, provides the ability for some GCOS jobs to run under the 
eontrol of Multics. 


This manual contains descriptions of the following Multiecs Priced Separate 
Products (PSPs); some of them may not be installed in your system. 


$GS6801 
GCOS (III) TimeSharing Environment Facility 


SGS6804 
GCOS (III) Batch Environment Facility 


The following are the primary reference manuals for user and system programmers 
of the Multics system. These manuals contain general information and may be 


referenced throughout this document. For convenience, these ref?rences are as 
follows: 


Document Referenced In Text As 


Multics Programmer's Reference Manual Programmer's Reference 
(Order No. AG91) 


Multies Command and Active Functions Commands 
(Order No. AG92) 


Multics Subroutines and I/0 Modules Subroutines 

(Order No. AG93) 

There are also frequent references within the text to the titles of the GCOS 
manuals listed below by title and order number. 

General Comprehensive Operating Supervisor (GCOS), Order No. DD19 

Control Cards Reference Manual, Order No. DD31 

File and Record Control, Order No. DDO7 


Time Sharing System Reference Manual, Order No. DJ31 


The information and specifications in this document are subject to change without notice. Con- 
sult your Honeywell Marketing Representative for product or service availability. 
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Often, user typed lines and lines displayed by Multies are shown together in the 


same examples. 


To differentiate between these lines, an exclamation mark (!) 


precedes user-typed text. This is done only to distinguish user text from 
system-generated text, it is not to be included as partof the input line. Also, 
a "carriage return" is implied at the end of every user-typed line. 


Note: 


Because of page constraints in this document, certain character 
strings of data used in examples may not match exactly the 
information as seen onauser'sterminal. Thatis, the character 
strings in examples may be folded (contained on several lines), 
wnereas the actual interactive (live) session may display the 
same information on a single line or multiple lines with 
different line breaks than shown. 


Significant Changes in ANO5-02A 


e Deleted Section 3 (material is duplicated elsewhere in this nanual, or is 
eontained in other GCOS manuals). 


e Moved complete portions of Appendix Bto Appendix A and renamed Appendix B. 
The moved information (i.e., Appendix B to Appendix A) was under title of: 


Maintenance of the GCOS User Table (and all sub-headings) 
Installing the GCOS Daemon (and all sub-headings) 
Creating the GCOS SysDaemon User Directory Structure 


None of the moved information was changed, therefore no change bars appear 
on the moved data, or the Contents. 


s Deleted 


"Utility Commands Example" in Appendix B. 


e Added "Steps to Build GCOS Software and Library Files" in Appendix B. 
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SECTION 1 


GCOS SIMULATION WITHIN MULTICS 


The GCOS batch and time sharing simulators provide for executing GCOS slave 
jobs and time sharing subsystems on Multics. Other facilities in this group 
include the GCOS daemon and several commands that can be used for manipulating 
GCOS files. 


In this document, the term "GTSS" refers to the GCOS time sharing simulator 
on Multics, while the term "GCOS time sharing" refers to the native GCOS facility. 


These facilities are briefly described in this introductory section and 
more fully described elsewhere in this manual. For additional information on 
Multics facilities and terminology, refer to the Multics reference manuals listed 
in the preface of this document. 


MULTICS PROCESSES 


In learning to use either of the simulators, it should be kept in mind that 
Multics is a time sharing system and is primarily oriented toward interactive 
users. Each logged-in interactive user has what is known as a process, which 
comprises the set of procedures (programs) and data that are being used and the 
path of execution through these programs. A process is similar to a GCOS job, 
or time sharing session. Commands entered by the uSer are analogous to the 
activities in the GCOS job. For example, one command line is used to compile a 
program and another is used to execute the program. However, a process differs 
from a job in that the user can intervene after, or even during, each command to 
determine what is done next. 


Multics has a batch processing facility that allows a user to queue an 
absentee job. An absentee job is a file containing a set of Multics commands 
that are to execute at some later time and which is run without terminal interactions. 
If no time is specified, the job is run as soon as those preceding it in the 
queue have finished. When the job is run, an absentee process is logged in for 
the user and the commands in the absentee input (absin) file are executed as if 
they had been entered on the console by an interactive user. 


ror absentee processing, output intended for the console is automatically 
directed to an absentee output (absout) file, which can later be printed and 
examined by the user. It is assumed that there are no user interactions, or 
that the user has anticipated them and has placed appropriate responses in the 
absin file. 


In addition to interactive and absentee processes, there is another type of 
process known as the daemon process. Daemon processes are logged in by the 
Multics operator and usually remain logged in during the entire time Multics is 
operating. These processes perform functions that cannot be performed in a 
user's process for reasons of security or efficiency. 
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For example, daemon processes are used to run the high-speed printers, the 
ecard reader, and the card punch. Normal user processes usually are not permitted 
to attach these devices. User processes queue requests for the input or output 
of files. Daemon processes then carry out these requests in the order in which 
they appear in the queues. This method of processing is analogous to the processing 
of SYSOUT by GCcOS. 


Each process in the system has associated with it a personid and a projectid. 
These normally are written in the form person.project. 


* The personid is the registered name of the user (i.e., the name typed 
when logging in). 


So The projectid is the name of the project group in which the user 
works. It is used both for accounting and for access control purposes. 
It is possible for a user to be registered on several projects. Some 
examples include: 


I0. Sys Daemon runs printers, etc. 

GCOS. Sys Daemon runs GCOS batch jobs 
Smith.Applications ordinary user 

Jones.Multics Multics system programmer 
Jones.Applications Jones works on two projects 


While GCOS allows both accounting and file access information to be changed 
within a job (via multiple $ IDENT and $ USERID control cards), Multics does not 
permit such changes within a process. 


GCOS BATCH ENVIRONMENT SIMULATOR 


The GCOS batch environment simulator is invoked via the Multics gcos command. 
The simulator immediately runs one GCOS job in the user's process. While the 
job is running, the user's process is completely dedicated to it and is not able 
to execute other Multics commands. 


The user's console is treated as the GCOS operator's console. Input and 
output intended for the GCOS operator's console are directed to the user's console; 
they do not appear on the Multics operator's console. 


When the job is finished, the user's process is free to execute other 
Multics commands or to run another GCOS job. It should be noted that the simulator 
runs only one job per call. No facilities are built into the simulator for 
batch processing, multiprogramming, communication between jobs, job scheduling, 
or resolving conflicting use of files or peripherals. 


The simulated interfaces are those seen by the job stream and by the executing 
Slave area program. The simulator reads card images from an input file, interprets 
the control cards, allocates the necessary files, and performs other initialization 
functions necessary to run each activity. 


During an activity, the simulator intercepts all MMEs (master mode entries) 
and performs the processing function requested by them. No provision is made 
for jobs that require special privileges, such as use of the MME ".EMM", 
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The simulator runs as an unprivileged user program under Multics and makes 
use of Multics facilities for all privileged operations such as input/output. 
Other GCOS features not simulated include: 

Transaction processing 
Remote I/O (except to the user's terminal) 


& 
& 
Cd Checkpoint, restart 
® 


File transfer between the simulator and native. GCOS on any. media other 
“than punchéd cards or magnetic tape 


Functions of the GCOS file system that have no counterparts in the 
Multics file system 


GCOS TIME SHARING ENVIRONMENT SIMULATOR 


rm eee 


The GTSS is invoked via the Multics geos tss command. The user may invoke 
the Multics gceos set_environment command before executing gceos tss to modify 
parameters regulating successive calls to gcos tss. 


GCOS time sharing simulation involves an interactive user interface that 
looks like GCOS time sharing and a simulated environment that allows a user to 
execute GCOS time sharing subsystems and user programs. The following functions 
are provided: 


1. Recognition of GCOS command language for each subsystem using tables 
extracted from the GCOS time sharing executive (module TSSA). Each 
command recognized has a corresponding list of primitives to be 
interpreted. 


2% Interpretation of GCOS time sharing primitives. There are a total of 
12 primitives to be interpreted. They provide for stacking ee current 
subsystem and calling a new one, initiating the loading and execution 
of the current subsystem program, initiating the building of input, 
returning to the subsystem at the previous level, manipulating bits in 
the subsystem switch word, and conditionally executing blocks of 
primitives under control of specified bits in the subsystem switch 
word. 


3. A command loader function to allow a user program stored on an H*® file 
to be loaded and executed. The command loader is invoked whenever an 
unrecognized command is given. 


4, A basic line editor which takes input from the terminal and merges it 
in line-numbered sequence with the current file. 


5, A static derail (DRL) handler similar to the MME handler in the GCOS 


batch simulator. This handler uses a transfer vector to cause the 
appropriate routine to be executed for each DRL. 
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GCOS DAEMON 


The GCOS daemon provides batch processing and some job scheduling facilities. 
Jobs can be submitted to Multics operations in either card deck or IMCV (input 
media conversion) tape form. The daemon examines the job and interprets some of 
the control cards for security, scheduling, and accounting purposes. It then 
submits an absentee job, which consists of commands, to call the simulator. The 
simulator runs the job and queues requests for the I/O daemon to print and punch 
the output. 


A separate absentee job is submitted for each GCOS job processed by the 
daemon. (See Appendix A for information on the use of the GCOS daemon facility.) 


FILE. SYSTEM 


The following discussion applies to both the batch and the time sharing 
simulators; although the interfaces are slightly different, the functions are 
the same. References that are simulator-specifiec are given as such. 


The GCOS file system is not simulated. Instead, references to permanent 
files from $ PRMFL or $ SELECT control cards, or from a MME GEFSYE are mapped by 
the simulator into references to files in the Multics file system. Many of the 
GCOS file system functions can be mapped into Multics. However, there are many 
comprehensive facilities within GCOS, for operating system-managed file integrity 
and concurrent access control, that are not accommodated. 


The Multics file system has several similariti to the GCOS file system. 
Multics files are identified by pathnames, which are analogous to the GCOS file 
String. They comprise a series of directory names, which are analogous to GCOS 
catalog names, followed by an entry name, which is analogous to a GCOS file 
name. Passwords are not included in a Multics pathname. 


Multics literature uses the term "Segment" when referring to items contained 
in the Multics file system. The term "file" is used in the special case of a 
segment that is being accessed by explicitly programmed I/0 rather than via the 
normal Multics method of direct-segment addressing. 


References to permanent files can be made from the simulator via a Multics 
pathname or via a GCOS file string. The Multics pathname can be used in place 
of the GCOS file string on the $ PRMFL card. 


File System Naming Conventions 


* The GCOS simulator character set for names may be composed of lowercase 
alphanumerics, period, and minus Signs. Names generated from within 
GCOS object programs are always mapped to lowercase. 


e A name consisting of zeros is specifically prohibited. Blanks are not 
permitted. If multiple-word names are desired then the words must be 
separated by periods or minus signs, not blanks. 


@ A maximum of eight characters is normally used for file names. Catalog 


names may be up to 12 characters and composed of the same characters 
as file names. 
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® To aecess a file with a name longer than eight characters in GTSS, an 
alternate name must be given to the file using a name from one to 
eight characters in length. 


® The greater-than (>) character is specifically prohibited in entrynames, 
since it is used to form pathnames. Other characters not recommended 
for entrynames are: 


Less-than (<), asterisk (*), question mark (?), percent (%), equal 
Sign (=), dollar sign ($), quotation mark ("), left slant (\), 
all ASCII control cha 


racters (tab, carriage return, etc.), and 
Parentheses. fs cote ae ie 


Non-ASCII characters are not permitted in entrynames. 


a The period must not be the first or last character of a name. Although 
this is allowed in native GCOS, it conflicts with the naming conventions 
of native Multics. 


CATALOG AND FILE PERMISSIONS: 


Each file has associated with it a Multics access control list (ACL), which 
is set by the owner of the file. The ACL can specify combinations of read, 
write, and execute permissions to individual users or to all users in a specific 
group. 


Access to permanent files from the simulator is determined only by Multics 
access control and is based on: 


1 The person.project of the process in which the simulator is running. 


2. The. access granted to that person.project by the ACLs of the files 
being referenced. 


When the simulator is running in an interactive user process, access privileges 
to any permanent files are the accesses granted to that person.project via the 
ACLs of the referenced files. The presence or absence of a $ USERID control 
eard has no effect on this access. (The $ USERID card is ignored by the simulator.) 


When the simulator is running jobs submitted by the GCOS daemon, there is a 
security problem. Normally, access to a Multics process (and its file access 
privileges) is validated by a password typed by the user at login time. However, 
a GCOS password is contained on a $ USERID card and is, therefore, much more 
susceptible to theft. Thus, in addition to the normal Multics file access controls, 
some additional restrictions are placed on jobs submitted by the daemon to protect 
the security of the Multics file system (see "Restrictions on Daemon Jobs" described 
later in this section). 
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PLE, 


SYSTEM ACCESS MODES 


Multics Access Modes 


GCOS 


The access modes for segments are: 


execute, e 
an executing procedure can transfer to this segment, and words of 
this segment can then be interpreted as instructions and executed by 
a processor. 


null, n 
no access. 


read, r 
this process can execute instructions that cause data to be fetched 
(loaded) from the segment. 


write, w 
this process can execute instructions that cause data in the segment 
to be modified. 


The access modes for directories are: 


append, a 
new segments, directories, and links can be created in the directory. 


modify, m 
the attributes of existing segments, directories, and links contained 
in the directory, and certain attributes of the directory itself can 
be modified. In addition, existing segments, directories, and links 
contained in the directory can be deleted. 


null, n 
no access. 


Status, s 
the attributes of segments, directories, and links contained in the 
directory, and certain attributes of the directory itself can be 
obtained. 


Permissions 


The permissions for both files and catalogs are: 


append, a 
allow transfer of information from file to program, but not from 
program to file (equivalent to read access). 


create, c 
allow catalogs and files to be entered as subordinate to this catalog. 


exclude, x 
the specified user has no access to the catalog or file. 


execute, e 
allow object code in the file to be executed. Execute permission is 
applicable only to time sharing. 


lock, 1 
allow MME or directive to security lock the file or catalog, or to 


remove an existing security lock (security lock does not apply to a 
user with lock permission). 


modify, m 
allow catalog or file descriptor to be modified. Allow entries to 
be made in catalog for subordinate files or catalogs. Users permitted 
to modify are allowed to perform any actions -- hence, modify includes 
create, lock, and purge, which in turn includes recovery and thus 
write and read. 


purge, Pp 

~~ @llow file to be deleted; or catalog and all Subordinate files to be 
deleted. Users with purge permission can also perform any of the 
actions permitted by recovery, including write and read. 


read, r 
allow transfer of information from file to program, but not from 
program to file. 


recovery, rec 
allow write when the file is abort locked, or when the file has 
defective space. Also, accept MME or directive to abort lock the 
file, or to reset an existing abort lock. Users with recovery permission 
are also given write and read permission. 


Write, w 


allow transfer of information from file to program and program to 
file (users with write permission thus have read permission). 
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MAPPING PERMISSIONS FROM GCOS TO MULTICS 


The following chart defines the actual Multics permissions used to simulate 
the desired GCOS permissions. To determine which Multics permissions are set, 
find the desired GCOS permissions (at the top of the chart) and read the corresponding 
(vertical) Multics permissions for that column. 


(create catalog) (create a, 


GCOS ———-..- 
outs ee Ee Be es oY ee ee 


Notes: 1 Needed to allow deletion by other users. (This access 
also allows these users to delete other segments.) 


Modify, which is necessary to allow changing of file 
permissions, also allows deletion of all segments under the 
directory. 


3 Permissions set on initial ACL s on segments. 


ACLs set on the created directory. 


ACLs set on the 


segment created. 


ACLs which must be set on the superior directory. 


In order to access a gtss file, the user must have: 


a. sma on the containing directory 
b. Ss on the directory superior to the containing directory 


MAPPING OF FILE STRINGS TO PATHNAMES 


Because the structure of the Multics file system is different from that of 
the GCOS file system, the appropriate method of mapping a GCOS file string into 
a Multics pathname is not an obvious one. The default method used allows many 
GCOS jobs to run immediately and requires that some initialization be performed 
in the Multics file system before other jobs can run. 


1-8 | ANO5-02 


Both the GCOS and Multies file systems are organized in tree-structured 
hierarchies. However, while the GCOS file system holds only user files, the 
Multics file system holds the entire Multics system; user files are held in a 
subdirectory of the total hierarchy. 


The user file subdirectory contains project directories and each of these 
contains individual user directories. The user file subdirectory is analogous 
to the system master catalog (SMC) of the GCOS file system. However, the project 
directories that it contains are not analogous to the user master catalogs (UMC) 
in the GCCS file system, since Multics users are not normally permitted to 
create or modify files in the project directories. 


User directories are more nearly analogous to the GCOS UMCs, but they differ 
in that they have two-component names, while UMCs have only one-component names. 
This makes it impossible to map UMC names directly into user directory names 
without obtaining additional information from some source or making some assumptions. 


The following paragraphs describe in detail how each mapping method works. 


A user directory, which is contained in a project directory, is known as a 
home directory in Multics terminology. The form of a home directory pathname 
is: 


>udd>project>person 


The greater-than sign (>) is used to separate components of a Multics pathname 
(instead of the slash (/) that is used in GCOS file strings). The leading > 
indicates the pathname is relative to the root of the hierarchy rather than 
relative to the working directory. The directory udd (user_directory directory) 
contains all project directories. Every user's home directory is contained in 
some project directory. For example, the home directory pathname of the user 
Smith.Applications is: 


>udd>Applications>Smith 


User files can be placed in the home directory. Users also can create 
subdirectories in the home directory and can place files in them to organize 
and/or restrict access to groups of files. Multics does not associate passwords 
with individual directories or files; access is controlled only by the ACL of 
the directory or file in question. 


Each process has a working directory. Initially, this directory is the 
home directory of the user. However, it can be changed by the user. 


With Multics conventions, files can be referenced by an absolute pathname 
or by a relative pathname. An absolute pathname begins with a greater-than sign 
(>) and contains the names of all the directories superior to the file in the 
hierarchy. For example: 


>udd>Applications>Smith>data file 

A relative pathname does not begin with a greater-than (>) sign and the 
complete pathname is assumed to begin with the pathname of the working directory. 
The simplest example of a relative pathname is an entry name (analogous to a 


GCOS file name): 


data file 
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This identifies the same file as the previous example, provided the working 
directory is: 


>udd>Applications>Smith 


Similarly, a GCOS catalog/file string that uses a leading UMC name can be 
considered to be an absolute pathname, and a file or catalog string that does 
not have a leading UMC name is considered to be a relative pathname. 


The method of mapping file strings to pathnames differs between the GCOS 
batch simulator and the GTSS. These differences are described in the following 
paragraphs. , 


Mapping Under GCOS Batch Simulator 


ee 


Multics absolute or relative pathnames can be used on $ PRMFL and $ SELECT 
ecards. They are interpreted as previously described. If a GCOS file string is 
used on one of these cards or in a MME GEFSYE, it is mapped into a Multics 
pathname: 


Ts All passwords, along with the dollar signs that precede them, are 
removed from the string and ignored. 


os All slashes (/) are changed to greater-than signs (>). 


3. The first catalog name in the string (that of the UMC) is replaced by 
the default working directory pathname (not the current working directory 
pathname). The default working directory is normally the same as the 
home directory, but it can be altered by the user with the 
change default wdir command. If no catalog string precedes the final 
string, the final string is appended to the pathname for the user's 
current working directory. 


Therefore, the file string: 

SMITH/JONES$CAT/Y $DOE 

is transformed to the pathname: 
>udd>Applications>Smith>jones>y 


for the user Smith.Applications. Note that the retained portion of the file 
string is indicated in lowercase letters, while the original file string is 
indicated in all capital letters. This illustrates a common situation in which 
a file string is encountered on a BCD (binary coded decimal) card that was used 
as input via the GCOS daemon. (Alphabetic BCD characters are translated into 
lowercase ASCII characters for internal processing by the simulator.) However, 
if the input is a Multics ASCII file, the original characters (uppercase or 
lowercase) in pathnames and file strings are preserved. A complete description 
of the use of the ASCII and BCD character sets is included in Section 2, under 
"Data Formats." 


Problems that arise while mapping file strings into pathnames (while accessing 
the files of another user) can be solved in two ways: 


1s Repunch the cards using Multics pathnames. 
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ae Place links in the home directory, which points to the files of interest 
in the user's directory. (See the Programmer's Reference manual for 
link information.) 


Mapping Under GTSS 


Ama 


GTSS does not allow the user to directly specify Multics pathnames in GCOS 
time sharing commands. This would be impractical because such commands are 
processed directly by GCOS time sharing subsystems. 


The GTSS user is provided with a choice of three rules for mapping GCOS 
file strings to Multics pathnames. The rules are UMC (User Master Catalog), SMC 
(System Master Catalog), and WD (working directory). The default is WD, which 
may be changed through the gcos set environment command. 


The first two steps of the mapping process are the same for GTSS as for the 
GCOS batch simulator: 


Ts All passwords, together with the dollar signs that precede them, are 
removed from the string and ignored. 
2% All slashes (/) are changed to greater-than signs (>). 


Further mapping action depends on the selection of one of the mapping rules 
described in the following paragraphs. 


MAPPING RULE: WD 


The first catalog name in the string (that of the UMC) is replaced by the 
working directory pathname. 

If the user's working directory is: 

>udd>Applications>Smith>temp dir 
then the file string: 

SMITH/ JONES$CAT/Y$DOE 
iS transformed to the pathname: 


>udd>Applications>Smith>temp dir>jones>y 


MAPPING RULE: UMC 


This rule for pathname mapping converts the leading UMC name in the GCOS 
ecatalog/file string into the string >udd>ume name>ume name. The purpose of this 
mode is to allow direct mapping of pathnames in either direction with no explicit 
action on the part of the individual user. This mode is used by the gcos fms 
command for the loading of GCOS user SAVE tapes onto Multics. 


The use of this rule requires that the Multics system administrator add the 
lowercase version of the UMC name to the project directory under >udd. The 
project administrator must create a directory by the same name directly below 
the project directory. This second directory is the equivalent to the catalog 
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for the given UMC on native GCOS. For example, a project on GCOS has the UMC 
name of DEBUG. This project is also registered on Multics, but with the name 
GDEBUG. The following steps must be taken to use the UMC mapping rule: 


ins add name >udd>GDEBUG debug 
2. create dir >udd>debug>debug 
2 set_acl >udd>debug>debug sma * ,GDEBUG 


y, set iacl seg >udd>debug>debug rw *.GDEBUG 


The GCOS catalog/file string of SMITH/JONES$CAT/Y$DOE would be mapped to: 


>udd>smith>smith>jones>y. 


MAPPING RULE: SMC 


This rule for pathname mapping sets a directory pathname specified by the 
user to be the root directory for all subsequent mappings. All UMCs are looked 
for or created directly under the SMC directory. Thus, the user has complete 
control over the mapping of GCOS catalog/file strings to their targets on Multics. 
Typically, the user creates links with the names of UMCs that point to the 
corresponding directories containing the desired subcatalogs and files. For 
example, the user has specified: 


-directory mapping smc -smc_pathname >udd>GDEBUG 


in a command invocation of gcos set environment. With this mode, the GCOS 
catalog/file string of “SMITH/ JONES$CAT/Y$DOE is mapped to 
>udd>GDEBUG>smith> jones>y. 


GCOS File Attributes 


An interim mechanism is used for the processing of GCOS file attributes. 
File attributes include the sequential/random creation mode, maximum file size, 
and current file size. 


The data attribute required by GTSS is converted to ASCII representation 
and saved as added names on the branch. The general form of the attribute name 
Css 


<entryname>.<attributename>.<attributevalue> 


Only GTSS requires these attributes. For files and catalogs created under 
GTSS, no user action is necessary to set or maintain this information. If files 
are created outside of GTSS, but are to be accessed under GTSS, the user must 
manually set this information? An exec com is provided to allow GCOS-oriented 
users to manipulate these added names. To use the exec con, type 
"ec >unb>gcos file attributes.ec path", where path is the pathname of the file 
to be accessed under GTSS. 
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RESTRICTIONS ON DAEMON JOBS 


To prevent the security of the Multics file system from being compromised 
by a GCOS job submitted via the daemon, three mechanisms are used. 


Ve 


The daemon submits all jobs under the process’ identification 
"Anonymous.GCOS.g". The Anonymous person identification is the standard 
Multics name used to identify an unknown user (whose right to use the 
System has not been verified) as well as to identify a known user. 
User files whose ACLs contain the entry "null Anonymous.*.*" are completely 
protected from daemon jobs v7 


The Multics ring protection mechanism is used to force daemon jobs to 
run in a less privileged ring than interactive user processes normally 
run in. The ring protection mechanism is described in the Programmer's 
Reference manual. 


This mechanism is an extension of the two-level (supervisor/user) 
protection feature found in most computer systems. Ring protection 
provides eight levels of privilege (ring 0-7) with ring 0 having the 
highest privilege and ring 7 the lowest. A process has a current 
execution level equal to one of the ring numbers and is said to be 
executing in that ring. The hardcore supervisor executes in ring 0. 
Normally, user processes execute commands in ring 4 (the "user ring"). 


Each file has a set of ring brackets, which are specified by three 
ring numbers. The ring brackets operate in addition to the ACL to 
restrict access to a file. A file whose ring brackets are [1 5 5] can 
be executed in rings 1-5, written in rings 0 and 1, and read in rings 
0-5. (This is determined from the first two numbers (1 and 5). The 
third number specifies the gate bracket, which controls changes in the 
ring of execution.) A file whose ring brackets are [4 4 4] can be 
written and read in rings 0-4 and executed only in ring 4. 


System commands and subroutines (including the GCOS simulators) have 


ring brackets of [1 5 5]. User-created files have brackets of [4 4 4] 
by default, since they are created by a process executing in ring 4. 
User file ring brackets can be changed using the set_ring brackets 


command. 


The daemon causes the absentee processes that it creates to run jobs 
for execution in ring 5. These processes thus will be denied access 
to all files whose ring brackets are [4 4 4H], even if the ACLs do 
not deny access to the process. Files created by these processes have 
brackets of [5 5 5] and are accessible to interactive users running 
in ring 4. 


Interactive users who wish to grant daemon jobs access to their files 
can do so by setting brackets of [5 5 5] on the files and placing 
Anonymous.GCOS.g on the ACLs. 


To create and delete files, a daemon job needs both modify and append 
permissions on the directory containing the files. To avoid the necessity 
of interactive users giving Anonymous.GCOS.g those permissions on the 
directories they use interactively, a separate hierarchy of GCOS files 
is maintained. This hierarchy is analogous to >udd (its name is >gdd), 
but it contains project and user directories only for GCOS users. 


The absentee jobs submitted by the daemon begin with a command that 
changes the home directory to >gdd>project>person, where person and 
project are determined by a table lookup of the account number on the 
$ IDENT control card. This causes GCOS file strings on $ PRMFL and 
$ SELECT control cards to be transformed into pathnames in the >gdd 
hierarchy. (However, Multics pathnames on those cards are not changed.) 
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For example, in the GCOS card deck, which includes: 


1 A ¢ IDENT card with a user accounting code that transforms to Smith.Test 
es A $ PRMFL card with the string: 
JONES $PASSWORD/ CATALOG 1/CATALOG2/FILENAME 1 


the file is interpreted as >gdd>Test>Smith>catalog1>catalog2>filename 1. 


The interactive Multics user who also submits batch GCOS jobs via the daemon 
should be allowed status/modify/append access to the directory >gdd>project>person 
to permit the sharing of data bases between these two environments. Since the 
user's execution level is 4, no difficulties are encountered in attempting read 
or write accesses to files (bracketed [5 5 5]) under this subtree. 


Similarly, when it is necessary for a batch GCOS job to access a file that 
is created interactively, the ACL must be set appropriately for Anonymous.GCOS.g 
and its brackets set to [5 5 5] (or higher). 


JOB SCHEDULING 


The $ MSG3 control card is used by the daemon to defer the start of an 
absentee job until the time requested on the card. The daemon uses the $ SNUMB 
card urgency field to select the priority queue in which the absentee job should 
be placed. The daemon rejects a job if another job with the same snumb previously 
was submitted and has not yet cleared the system. 


With the exception of these two cards, there are no facilities in either 
the daemon or the simulator for scheduling, holding, or resolving conflicting 
resource usage among jobs. Jobs attempting to modify the same permanent files 
must be manually scheduled to avoid conflicts. Jobs that use many tape drives 
must be scheduled so as to avoid lockups between them (i.e., each job waiting 
for tape drives that were allocated to the other). 
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SECTION 2 


GCOS BATCH ENVIRONMENT SIMULATOR DESIGN AND OPERATION 


ORGANIZATION 


The GCOS batch environment simulator (invoked by the gcos command) comprises 
three major parts: the input reader; the allocator, and the MME simulator. 


The input reader reads the input file (which can be either ASCII or BCD), 
merges in any $ SELECT files (each of which can be either ASCII or BCD), translates 
the card images to the format expected by the allocator, and writes the images 
into the job stream file. The input reader also checks for execution activities 
(for later setting of program switch word bit 5) and performs a limited amount 
of checking for control card errors. Most of the control card error checking, 
however, is performed by the allocator. 


The allocator reads the control cards and data cards for each activity from 
the job stream file that is created by the input reader; allocates the files to 
be used by the activity; interprets some control cards; and writes other control 
ecards and data ecards onto files for later interpretation by a slave PLORTam: 
The allocator then calls the MME simulator. 


The MME simulator replaces the signal pointer in the header of the user's 
Stack, so that the simulator's MME handler is the first user ring program to 
receive control following a fault (rather than Signal , which is the normal user 
ring fault handler). The MME simulator also establishes a handler for faults, 
such as overflow and underflow, that is called by signal if control ever reaches 
it. A MME GECALL, which contains the name of the slave program to be executed, 
is constructed and placed in the slave area segment. Control then is transferred 
to the MME GECALL. 


The software library is searched, the program is loaded, and execution 
begins. 


Whenever a MME or any other fault occurs, the Multics hardcore supervisor 
performs initial processing. If the MME or fault is not one that must be handled 
by the supervisor, it is passed on to the fault handler in the user ring. Since 
the MME simulator substitutes its own handler for signal , that handler receives 


If the fault is a GCOS MME, the simulator calls a subroutine to perform the 
service requested by the MME. Control then is returned to the slave program. 


If the fault is not a MME, the simulator calls signal . Eventually, if the 
fault is one that can be handled by the slave program, the simulator's fault 
handler examines the fault vector in the slave program and either transfers to a 
handler in the slave program or takes appropriate action itself. 
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When a MME GEFINI occurs, the MME simulator returns control to the allocator. 


All activities are run in this manner. When all activities have been run, 
the simulator converts SYSOUT print and punch files to ASCII and raw files 
respectively and submits them to the I/O daemon for printing or punching. (The 
conversion and the daemon requests can be prevented by using gcos command options.) 


Note that successive compilations are run as separate activities and can 
cause the limit of 63 to be exceeded. 


A single segment is used to simulate the slave area (the slave area is 
limited to 256K). The slave service area does not exist in the GCOS environment 
Simulator. While the slave area prefix exists, its contents are not always 
guaranteed to be identical to that in native GCOS. The slave area is placed in 
the process directory and is named gcos slave area Seg. 


GCOS SOFTWARE DATA BASES 


The subroutine library (L*) is a multisegment file named 
gcos library subroutines . (This library is known to gcecos tss by its add name 
gtss Lstar .) It is a reformatted version of the file SOFTW-SYSLIB from a GCOS 
total system tape. Other subroutine libraries may be installed with the commands 
described in Appendix B and accessed via the $ LIBRARY and $ PRMFL cards in the 
job deck. (Any of these alternate subroutine libraries installed in the same 
directory as gcos library subroutines and given the add name gtss starL_ becomes 
known to geos tss as the *L library.) ~ ~ 


The software library, which contains compilers, etc., is a muitisegment 
file named gcos system software . Its catalog is not in the same format as the 
one created by the system editor and, therefore, it cannot be updated by the 
system editor. The programs described in Appendix B are used to update this 
file. The GECALL, GESAVE, and GERSTR MMEs all accept this nonstandard catalog 
format, as well as the system editor random library format. 


The simulator normally uses the copies of these two libraries that are 
found in the Multics system library. However, if the -userlib control argument 
is given on the gcos command line, the simulator searches for and uses (if 
found) copies of these libraries supplied by the user. It also uses a secondary 
library, which is searched after the software library. The effects of the -userlib 
argument are: 


© The search rules used in the search for the libraries are modified by 
placing the referencing dir rule last. This allows a file contained 
in a directory in the user's search rules (such as the working directory) 
that has the same name as one of the libraries to be found before the 
file of that name in the Multics system libraries. 


2. The file named gcos second software is sought by using the modified 
search rules previously described. If it is found, the file is searched 
via MME GECALL if the requested module is not found in the primary 
software library (gcos system software ). This differs from a ** file, 
which is searched before the primary software library. 


Both of these user-Supplied libraries may be constructed using either the 
programs described in Appendix B, or the system editor. 


2-2 ANO5-02 


INPUT/OUTPUT OPERATIONS 


Slave program I/O operations under the simulator, as under native GCOS, are 


initiated via a MME GEINOS instruction, which is followed by a select sequence 
specifying additional information pertaining to the I/0 operation. This gives 
control to the simulator. The simulator then calls the standard Multics procedures 
to initiate activity on the peripheral subsystems. 


The simulator performs actual device specific I/0 only to magnetic tape 
devices. All other I/O devices are simulated by files in the Multics storage 
system. Print and punch output files are (optionally) converted to Multies file 
formats and printed or punched by Multics, after the GCOS job has ended. A 
separate Multics file is used to simulate each GCOS file used by the job. (The 
term "file" refers either to a segment or a multisegment file.) 


Physical I/0, either to tapes or files, is performed by the Multics I/0 
system, which has complete control over the allocation of devices to user processes 
and the initiation of actual I/0 operations. Since all I/0 is done by Multics, 
the function performed in the native GCOS environment by MME GEROAD is not 
required under the simulator. 


In addition, the simulator's I/O procedures provide the following capabilities: 


e Symbolic file code to physical unit translation. 


Files are referred to symbolically with two-character file codes. This 
provides maximum flexibility of file assignment at execution time because 
files that a program can uSe are device independent. 


e Simulated magnetic tape processing on disk. 


The simulator provides a method of disk processing that simulates the 
serial mode of processing normally associated with magnetic tape. This 
mode of processing (GCOS-linked) not only provides a degree of device 
independence to computer configuration, but also provides the opportunity 
to reduce program setup time by eliminating the use of magnetic tape 
for some files. 


@ File system protection. 


The simulator ensures that the user has been granted permission for 
permanent file access. This iS accomplished in two ways. First, the 
Standard Multics access controls ensure that the GCOS user has at 
least the minimum permissions necessary to access another user's permanent 
files. In addition, simulator I/O procedures validate all I/0 requests 
against the I/O modes requested on the $ PRMFL control card. This 
prevents a job from requesting only read permission on a permanent 
file and then erroneously writing on that file. 


Other native GCOS IOS (Input Output Supervisor) functions such as I/0 interrupt 
processing, queving of program I/O requests, and channei crossbar management are 
performed by Multics and are not part of the GCOS environment simulator procedures. 


The simulator, operating under Multics, performs the logical functions 
necessary to interface the GCOS slave program I/0 request to the Multics I/0 
system: 
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e Linking files to devices, which are allocated to the job through a 
Multics I/O stream : 

& File code to I/O stream translation 

e File protection of user files 

e Pseudo magnetic tape processing on disk/drum 

a Simulation of the GCOS courtesy call dispatching mechanism 


GCOS ENVIRONMENT SIMULATOR FILES 


The Multics storage system is used by the Simulator for: 


ds The GCOS subroutine and software libraries (including assemblers and 
compilers) 
2. GCOS environment permanent executable modules, permanent control tables, 


and temporary segments containing information specific to each job 
3. GCOS save user temporary files 
4, The slave core image seen by the executing slave program 
5. SYSOUT collection space 
6. GCOS user permanent files 
fe System temporary files as required by the various language processors! 


utility programs 


For a description of native GCCS system files, refer to the General Comprehensive 
Operating Supervisor (GCOS) manual. 


GCOS Pool 


rte 


The GCOS pool is a project directory of the GCOS daemon's directory (>ddd>GCOS) 
that functions in a manner similar to the SYSOUT pool in native GCOS. It can be 
used to contain the temporary files of a GCOS job. These files include the 
System-created input and working files, as well as files to contain SYSOUT output. 
In addition, the pool can be used to hold output "written" to the pseudoprinter 
and the pseudopunch under the simulator. 


For the purposes of accounting, project and user directories containing 
permfiles exist under >gdd. 


User Files 


GCOS environment simulator users operate on mass storage files through the 
facilities of the Multics storage system. Both permanent files (nonremovable) 
and temporary files are processed by GCOS programs in the normal manner. The 
Multics features of paging and segmentation are transparent to simulator users. 
All GCOS files are actually Multics segments with no special attributes. Since 
they are one and the same, access to the files can be either by GCOS slave 
programs operating under the simulator or by any Multics procedure. 
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File Formats 


Files to be used by a job executing under the simulator can exist either in 
the Multics storage system (in the form of paged segments) or on magnetic tape 
in the same logical structure as that under native GCOS. Files on magnetic tape 
can be processed by the same slave program operating under either the simulator 
or native GCOS. 


Data formats are identical to those for native GCOS. Since the simulator 
interfaces with the slave software at the MME level, all Multics-supported GCOS 
. Slave program eontent managers ¢such as file and record control) define the 
content and format of the data to be read or written. 


Standard GCOS access modes (sequential and random) are supported by the 
Simulator. Thus, the access mode for a particular mass storage file, as determined 
at the time of file allocation (or as defined by the MME GEMORE mode change), 
causes the routine that simulates the MME GEINOS either to supply the desired 
I/O address for the user or to use the user-supplied I/0 address. 


File Orientation 


The GCOS environment Simulator assigns pseudoperipheral devices to an activity 
via file code designators and manages these peripherals during I/O operations. 
The programmer references all peripherals by using the file code designators 
(two alphanumeric characters) that are referenced in two ways: 


@ On file control cards that specify those files needed to execute an 
activity 
@ In communicating to the file and record control program, or to the 


Ssimulator's input/output supervisor 


The file code designators and their assigned file information blocks (FIB) 
are used by the simulator for peripheral identification and management. The 
FIBs are Similar to the peripheral assignment tables (PAT) used by native GCOS 
in that each contains a description of a file and each can be pointed to by one 
or more file codes. 


File Names 


Temporary and output files created by the simulator are placed in the Multics 
file system hierarchy. The complete pathname of each file comprises a directory 
name (the complete pathname of the directory containing the file) and an entry 
name (the equivalent of a GCOS file name). 


Each directory in the hierarchy either has a quota (a limit on the total 
Space occupied by the files it contains), or borrows a quota from a superior 
directory. Quota is measured in records. One record equals one Multics page, 
which is 1024 words. 


Jobs that produce a large amount of output or use large temporary files 
could fail to complete normally if there is not enough quota in the directories 
being used to hold the files created by the job. The simulator allows the files 
to be placed in up to four different directories (three of which can be specified 
by the user) to help alleviate the quota problem. 
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The four directories are: pdir (process directory), wdir (working directory), 
syot_dir (SYSOUT directory), and temp dir (temporary directory). 


The pdir and wdir directories are defined by Multics. Each process is 
assigned a process directory when it is created (having a quota determined by 
the system). The current value of this quota is 512 records. Each process has 
a working directory, which is initially the home directory of the user but can 
be changed (using the change wdir command) to any directory to which the user 
has access. a 


The syot dir and temp dir directories are defined by the simulator. They 
are, by default, equal to wdir and pdir respectively, but they can be set to any 
directories to which the user has access (using the -syot_ dir and -temp dir 
control arguments on the gcos command line). 


Files are placed in directories on the following basis: 


Directory Files 

pdir gcos Slave area seg 

temp dir all temporary GCOS files 

syot_ dir all GCOS output (print, punch, and SYSOUT files) 
wdir converted (ASCII or raw) copies of output files 


The entry names of temporary and output files begin with the job identification 
(job id). By default, the job id is the entry name of the input file with the 
gcos suffix removed (if it is present). However, the job id can be set to any 
name by using the -id control argument on the gcos command line. 


Standard output files have the names: 


job _id.sysprint 
job_id.syspunch 
job _id.exec report 


The exec report file is copied into the sysprint file and deleted at the 
end of the job. However, it might be found in the syot dir if simulation terminated 
abnormally. The sysprint and syspunch files contain all print and punch records, 
respectively, as written via the MME GESYOT instruction. 


Any additional output files and all temporary files have names of the form: 


job_id.a<activity number>.<+file code> 


where: <activity number> is the number of the activity in which the file was 
first created. 


<+filecode> is the file code, with asterisks replaced by plus signs (to 
avoid interfering with the Multics star convention, which assigns a special 
meaning to asterisks in file names). 


For example, a job whose input file is named testjob.gcos has output files 
named: 
testjob.sysprint 


testjob.syspunch 
testjob.exec report 
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If the job consists of a compilation followed by an execution, the B* file 
containing the object code from the compilation is named: 


testjob.al.b+ 


and is placed in temp dir. If the second activity contains a $ PRINT...P* control 
ecard, the file used to simulate the printer is named: 


testjob.a2.p+ 


and is placed in syot dir. 


If the simulator default output processing (converting GCOS output files to 
Multics format) is not overridden by control arguments, the converted output 
files are named by appending "list" or "raw" to the GCOS file names for print 
and punch files respectively. Continuing the preceding example, the converted 
output files would be named: 


testjob.sysprint.list 
testjob.a2.p+.list 


and (only if punched card output is actually produced by the job): 
testjob.syspunch.raw 
Note that the exec report file does not have a corresponding list file 
because it is copied onto the sysprint file and then placed at the beginning of 


the sysprint.list file at the time the rest of the SYSOUT is sorted by report 
code. 


JOB INPUT 


The Simulator is invoked via the gcos command to run one GCOS job at a time 
one Multics process. Many users can be calling the gcos command simultaneously. 
ch 


n 
atch processing is provided by the GCOS daemon. 


i 
B 


Functions performed inline by programs comprising the simulator include 
control card interpretation and MME processing. Other functions are provided by 
GCOS slave software that is executed under simulator control in the same manner 
aS a user-written program (file and record control, general loader, and language 
translators). 


GCOS Command 


The gecos command invokes the GCOS environment simulator and initiates job 
processing. The command is used after the job stream has been entered into a 
file by the user or by the GCOS daemon. The format of the geos command is: 


gcos job_deck path {-control arguments} 


This command is described in detail in Section 3. 


Job Decks 


Jobs punched on cards can be submitted to the simulator in two ways: 
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e The job deck can be submitted to the GCOS daemon. The deck is read by 
an online card reader under control of the daemon and an absentee job 
is submitted to run the GCOS job. (See Appendix A for more details.) 


* The job deck can be submitted for input to a segment by using the 
Multies bulk card input facility (refer to the Programmer's Reference 
manual for information on this facility). The raw input mode must be 
used. Then, the geos card utility command must be used to convert the 
resulting segment to a format acceptable to the simulator. The converted 
segment can be used as input to the simulator either in an interactive 
process or in an absentee job submitted by an interactive process. 


IMCV Tapes 


IMCV options available under native GCOS also are available under the GCOS 
daemon. IMCV tapes need only be in GCOS system standard format, as created by 
the bulk media conversion (BMC) program. (See Appendix A for more details.) 


Data Formats 


The job deck file supplied to the simulator (and any $ SELECT files) can be 
in either of two formats: 


@ Multics ASCII, as created by the Multics editors 


@ GCOS system standard format containing mixed BCD and binary card images 


ASCII format is assumed. GCOS format must be specified, either by the gcos 
suffix on the name of the input file, by the control argument -gceos on the gceos 
command line, or in the comments field of a $ SELECT control card. 


When a mixed BCD and binary card deck is submitted to the daemon, the deck 
is read in raw mode and translated to GCOS system standard format. If a card 
deck is read into a user's segment via bulk card input in raw mode, the deck 
must be converted to ASCII or to GCOS system standard format before being used 
as input to the simulator. (If the deck contains binary ecards, it cannot be 
converted to ASCII.) 


Like all other Multics software, the simulator uses the ASCII character set 
internally. However, the GCOS slave software that runs under control of the 
Simulator uses the BCD character set internally. Therefore, the images of cards 
processed by the simulator must be in ASCII, while those processed by the slave 
software must be in BCD. 


All nondollar cards (refer to Section 5 for definition) are processed only 
by the slave software and, therefore, should be in BCD (unless they are binary 
eards). All dollar (control) cards are processed by the simulator. However, 
many also are written on files for processing by the slave software. Therefore, 
both an ASCII and a BCD copy of each dollar card are needed. 


The simulator's input reader accepts whatever format input file is provided 
and creates a job stream file containing the necessary ASCII and BCD card images. 
This involves some translations from ASCII to BCD and vice versa. Since the 
ASCII character set contains both uppercase and lowercase alphabetic characters 
and BCD contains only uppercase, some problems arise in translation. 
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Following the Multics convention of using lowercase alphabetic characters 
for most purposes, the simulator uses lowercase characters for control card 
names, control card options, file codes, and other character strings that GCOS 
users are accustomed to seeing printed in uppercase (BCD). 


All BCD-to-ASCII translation performed by the simulator produces lowercase 
ASCII alphabetic characters (job output is an exception). 


Control cards must be in lowercase when entered into an ASCII segment via 
one of the Multics editors. (Nondollar cards, which are translated to BCD, can 
-be-in-either-case,;-since-both uppercase and lowercase ASCII letters are translated 
to the same BCD codes.) 


The only exception to the requirement for lowercase ASCII on control cards 
is in Multics pathnames on $ PRMFL and $ SELECT cards. Multics pathnames can, 
and generally do, contain uppercase letters. These uppercase letters most frequently 
are the first letter of person and project names. 


Since BCD is translated to lowercase ASCII, it is not possible to punch a 
Multics pathname containing any uppercase letters on a BCD card. However, GCOS 
file strings have their first catalog name replaced by the home directory pathname 
of the process running the simulation. Therefore, if the pathname of the file 
(relative to the home directory) contains no uppercase characters, the pathname 
can be punched as a file string. This is likely to occur, since uppercase 
letters appear most frequently in person and project names that are part of the 
home directory pathname. 


Tab Replacement 


An ASCII job deck segment (or an ASCII $ SELECT file) can be typed by using 
tabs to position fields to the card columns required by GCOS. The tabs are 
translated into the proper number of spaces by the Simulator's input reader. 
This tranSiation is known as canonicalization. 


Tabstop positions vary with context. For nondollar cards, these positions 
are determined by the preceding activity card. For example, data cards following 
a $ FORTRAN card are canonicalized using a single logical tabstop in column 7. 


The following sets of tabstops are used: 


Tabstops Used For 

8, 16, 32, 73 dollar cards 

85 -'6;. 325.73 GMAP, 355MAP 

ome ee: FORTRAN, FORT77 

Oe, dep 1S COBOL 

10, 20, 30, 40, 50, 60, 70 PL1, ALGOL, JOVIAL, IDS, IDS2, CIDS2, RPG2 


The columns following the last tabstop in each set are treated as if each 
contained a logical tabstop. Also, cards for which no tabstops are defined are 
treated as if each column contained a logical tabstop. Therefore, a tab occurring 
in a position where no tabstops are defined is translated to a single space 
rather than moving the logical character position to the end of the card. 


The canonicalization process accepts the sequence tab-backspace to set the 
logical character position to the column before the next logical tabstop. However, 
the Multics terminal input software does not accept this sequence directly. 
Therefore, the backspace following the tab must be entered as some other character 
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and later changed to a backspace (using an editor). The uSer can choose some 
character that will not be used elsewhere in the file, type the character wherever 
a backspace is intended to follow a tab, and then change all occurrences of that 
character to a backspace. This is done by using a global substitution. 


If the file contains no tabs, processing time can be saved by using the 
-no canonicalize control argument on the gcos command line. This causes the 
canonicalization process to be omitted. 


ASCII input lines are checked for length exceeding 80 characters. Lf 
canonicalization is being done, the length after canonicalization is checked. 
If the -truncate control argument is given on the gcos command line, lines that 
exceed 80 characters are truncated to 80 with no warning. Otherwise, a line 
that exceeds 80 characters is treated as a nonfatal error. 


The action taken for a nonfatal error is controlled by the -brief and 
-continue control arguments. (See the introductory paragraphs of Section 5, 
concerning -brief and -continue.) 


Identification Process 


The simulator scans the first two records of the job input stream to ensure 
they are the $ SNUMB and $ IDENT control cards. If the job is submitted via the 
GCOS daemon, the $ SNUMB card must contain a sequence code (number) that is not 
already in the system (because the $ SNUMB code is registered in a table and is 
used to uniquely identify certain working files for the job.) 


Job Limits 


A GCOS job executing under the simulator is subject to resource usage limits 
in the following higher level functions: 


Slave memory must be less than 256K. 
Maximum of 63 activities per job. 


& All printer and card punch output is stored online until the end of 
the job. This is true even though the job thinks it has the device 
directly attached. Therefore, sufficient space is required. 


e A maximum of 40 files can be open at any one time. However, five of 
these files are dedicated to the subroutine library (L*), the execution 
report, the SYSOUT print and punch collector files, and the loader 
file (R*). The number of files that can be created per activity is 35 
minus the number of files currently saved from preceding activities. 
For example, if activity 1 saved four files and activity 2 saved two 
files, only 29 new files can be created by subsequent activities (35 
minus 4 minus 2) until some of the previously saved files are released. 
Note that the system files allocated for each activity are deducted 
from the 35 files, thereby leaving a smaller number of files than can 
be allocated by a user. Each activity can refer to any or all of the 
35 files. . 


Variable parameters, which can be varied via Multics startup control cards 
or by operator commands, include the number of tape drives that a process is 
permitted to attach and the number of concurrent absentee processes being processed 
in parallel. 
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ALLOCATION 


There are several differences between Multics and native GCOS in the manner 
in which the allocation, execution, and termination functions are accomplished. 
However, it is not the intent of the simulator to duplicate the implementation 
of native GCOS, but only to simulate its effects on jobs and slave programs. 
Thus, allocation of all system resources (peripherals, core memory, and processor 
time) comes under final control of Multics. The GCOS environment simulator 


Serves only as the intermediary. 


. When a new. job is received, an initial pass is made through ‘the input 
Stream. At this time, canonicalization of any ASCII input is performed, the 
contents of any $ SELECT files are copied into the input stream, the presence of 
execution activities is noted, and some limited control card checking is performed. 


During the second pass, detailed processing of the control cards for each 
activity occurs just before the activity is run. Control card errors cause the 
job to be aborted at this point, but preceding activities have already run. 


When an executing slave program initiates remote teleprinter I/0, the terminal 
I/O is to the user input and user output Multics I/O stream. These normally are 
attached to the interactive user's console. The program then can interact with 
a Multics user at the console in the normal manner. 


Peripheral allocation has three categories: 


1. Real devices (magnetic tapes, interactive user consoles, and all temporary 
mass storage files requested on the various $ control cards). 


2s Pseudo devices (printers and card punches). 


3% Devices not permitted (card reader, paper tape reader or punch, and 
removable disk packs). 


The simulator job stream input procedure reads all ecards from the canonicalized 
source up to the next activity definition card or activity termination card. 
All peripheral allocation control cards for magnetic tape result in allocation 
of tape handlers. During this phase, tape mounting instructions are issued via 
the Multics attach mechanism. 


Pseudoperipherals are allocated as the result of printer and card punch 
allocation. control cards. (The job cannot allocate a card reader.) A 
pseudoperipheral appears to be the actual peripheral device for the executing 
Slave program, but it actually is a segment in which the simulator retains the 
output. This segment then is processed in a manner similar to that used to 
convert SYSOUT output to a form acceptable to the Multics I/O daemon for printing 
or punching. 


After the peripherals and scratch files are allocated, memory is allocated 
for the activity. The simulator determines the amount of memory required (from 
the appropriate $ LIMITS control card definition) and creates a segment of this 
Size to hold the executing slave program. 


All mass storage allocation cards requesting temporary file space are processed 
in the same manner as those requesting peripheral allocation. A Multics segment 
is created with the appropriate size limitations. Both random and sequential 
access modes are processed through the simulator'ts I/O routines. 
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The simulator makes access to permanent files for the slave program. These 
files are permanent segments in the Multics storage system and are subject to 
the Multics permission modes defined for that segment. Passwords on $ PRMFL 
control ecards are ignored. 


Where appropriate, peripheral allocation for GCOS activities run under the 
simulator takes advantage of existing and newly implemented Multics facilities. 
Resource allocation conflicts, such as making access to a data base for updating, 
must be resolved by manually scheduling conflicting jobs for processing at different 
times. 


When the assigned peripherals are ready (sufficient memory is assumed), the 
activity passes into the execution phase. No job activity is initiated until 
all prior activities of that job have been completed. 


EXECUTION 


During execution, the activity is initiated in the same manner as native 
Gcos. Each activity is executed under the supervision of the simulator. All 
user communication with the simulator is provided at execution time by the MME 
routines, which provide requests for service, exchange of information, and control 
functions. Many of the MME routines are automatically called by the compilers 
and by file and record control programs. 


Once loaded and executing, the slave program is Similar to other procedures 
executing under Multics in that the segment is paged as necessary by the Multics 
paging mechanism. However, a Significant difference is that the segment containing 
the executing GCOS slave program must have Write permission for the user because 
procedures and data are intermixed. 


After termination of the first activity, control is returned to the simulator 
and processing for the second activity begins. 


Fault Processing 


Responses to any exception conditions or processor faults are executed during 
this phase. When an exception condition or fault is encountered, either standard 
actions are performed or the user is given the option of intervening, depending 
upon the particular error and the I/0 request. 


The method by which faults are processed depends upon whether the fault was 
caused by the simulator or by the slave program. 


If a fault (or other error) occurs within the simulator (rather than within 
the slave program), the user fault vector is not examined. Instead, the reason 
for the fault or error is printed on the user's terminal. Then, by default, the 
activity is aborted via a simulated MME GEBORT. However, if the ~debug control 
argument is given on the gceos command line, the user is given the opportunity to 
intervene, using Multics debugging tools, to determine the cause of the error 
and possibly to correct it. 


Slave program faults are interpreted by the simulator procedures. If the 
fault is because of a MME, the MME is analyzed and the appropriate simulator 
procedures are called to simulate the effects of native GCOS. 
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For program faults, the fault causes interrogation of the user fault vectors. 
If the user specifies a fault processing routine, control is transferred via 
this vector back to the slave activity. If no fault processing routine is 
specified in the user fault vector, a MME GEBORT is set in the user program and 
control is transferred to MME GEBORT. GCOS allows processing of the following 
program faults by a user error subroutine: 


memory 
divide check 

overflow 

command 

illegal operation code 
fault tag 

derail 


A user can process an unlimited number of divide check, overflow, and derail 
faults. However, a second attempt to process a fault tag, command, illegal 
operation code, or memory fault causes the program to abort, except under a 
special condition. The special condition is that the Instruction Counter and 
Indicator Register (IC and IR) word (even) of the fault vector pair is zero and 
the second word is nonzero. Under this condition, the simulator allows the user 
to process one of these faults after the first fault is processed. 


The user cannot invoke a fault processing routine for the following hardware 
faults: 


lockup 

parity 

startup 

execute 

connect 

shutdown 

timer runout 

operation not complete 


TERMINATION 


Three types of termination (normal, abnormal, or simulator fault) can occur 
when running a user activity under the GCOS environment simulator. 


In native GCOS, successive GMAP or FORTRAN activities (without intervening 
$ IDENT or file control cards) are run as a single GMAP or FORTRAN activity. 
Thus, a job containing ten FORTRAN compilations, followed by a $ EXECUTE control 
card, is run aS two activities (a FORTRAN compilation of ten routines and an 
execution activity). Under the simulator, each compilation or assembly is a 
Separate activity that undergoes termination. 


Normal Termination 


Normal activity termination occurs when a MME GEFINI is executed by a user 
program. If an activity terminates normally, the user does not get a dump, 
Wrapup, or an abort subactivity, regardless of whether the slave program prefix 
contains a wrapup address. 


The execution report is generated, peripheral files are released, and memory 
is released. 
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If the activity is the last activity of the job (delimited by a $ ENDJOB 
control card), a *EOJ message is issued on the console and the job is released 
for printer or punched output. If the activity is not the last activity, allocation 
of the next activity begins immediately. 


Abnormal Termination 


Abnormal termination can be caused by: 


Simulator-detected errors 
slave program requests (MME GEBORT) 
hardware-generated/system faults 


Any of these results in an immediate interrupt of the activity. Since all 
I/O is synchronous in the simulator, no I/O is lost in an abnormal termination. 


SIMULATOR-DETECTED ERRORS 


The locations of the fault or error and the reason code are placed in bits 
0-17 of word 13 (octal) of the slave program prefix. A ¥*ABT message is issued 
on the user's output stream. If bit 0O of the program switch word is on, a 
postmortem dump is generated. If word 27 (octal) of the slave program prefix 
contains a wrapup address, the word is cleared and the user is given control at 
that address. (This word normally is initialized by the ".SETU." routine if 
this is an execute activity.) After the (optional) wrapup terminates, bit 12 of 
the program switch word is examined. If the bit is set, a Utility subactivity 
is executed. Upon return from this subactivity, the activity is terminated. 


MME GEBORT 


In the case of a MME GEBORT, the program supplies the reason code; the 
Simulator provides the remaining data. The IC and reason code are inserted in 
word 13 (octal) of the slave program prefix: 


bits 0-17 IC (location of termination) 
18-20 2 (MME GEBORT reason code) 
21-23 Zero 
24-35 Reason code 


Memory and peripherals allocated to the activity are deallocated, and 
dismounting instructions are issued to the operator on the console. A postmortem 
memory dump is written on the execution report if bit 0 of the program switch 
word = 1. If the address (bits 0-17) of word 27 (octal) of the slave program 
prefix is within slave program limits, return is made to the user for wrapup. 
Then, the check for abort subactivity is made. 


HARDWARE-GENERATED AND SYSTEM FAULTS 


If a fault or other error occurs during the running of an activity (between 
the SRT and FIN messages on the user's terminal) and the simulator is unable to 
handle it, control passes to the Multics command processor. Execution of the 
job is suspended at the point of the fault. The user may wish to use Multics 
debugging tools to determine the cause of the error. After this is done, there 
are two possible courses of action: 1) to terminate the simulation immediately 
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with all output being lost, type "release", and 2) to reenter the simulator, 
possibly continue execution of the job, and to obtain output, type: 


gcos_ mme_ bort $simulatorbbxx 


where BB is one or more spaces and xx is any two characters (representing an 
abort code). Control is returned to the simulator, which simulates a MME GEBORT 
utilizing the two-character abort code required by the program. 


hensive Operating Supervisor (GCOS) manual for a 
a 


Refer to the General Compre 
apup, and abort subactivities and terminate messages. 


description of the dump, wr 


If a fault occurs in the simulator before or between activities and causes 
control to pass to the Multics command processor, Simulation of a MME GEBORT 
causes unpredictable results. 


There is an alternative to the preceding command that causes the job to 
terminate immediately. Output buffers are forced out, files are closed, and 
SYSOUT is generated (if possible). The command is: 


geos_ ce endjob_ 


This command causes the simulator to be entered at the $ ENDJOB control 
ecard processor, which performs the end-of-job processing previously described. 


JOB OUTPUT 


Job output comprises the SYSOUT (sysprint and syspunch) collection files, 
any print or punch files created by activities, and any permfiles created by the 
job. Permfiles remain in the Mulitics storage system when the job is finished. 
By default, all SYSOUT print and punch files are converted from GCOS to Multics 
format, placed in the working directory, and queued for output by the Multics 
I/O daemon. Control arguments on the geos command line can be used to request 
output processing other than the defaults. 


The sysprint generated by the slave programs is in BCD. The execution 
report produced by the simulator contains both BCD and ASCII records. ASCII is 
used for lines that might contain Multiecs pathnames, since uppercase and lowercase 
letters are significant and should be preserved. By default, BCD sysout is 
translated to uppercase ASCII to simulate the appearance of SYSOUT printed by 
native GCOS. The -lower_case control argument can be used on the gcos command 
line to cause BCD SYSOUT to be translated to lowercase ASCII. 


The GCOS SYSOUT line limits are enforced. The lines counted include only 
those supplied by the slave program, including MME GEBORT core dumps and MME 
GESNAP print lines. Refer to the Control Card Reference Manual, Order No. DD31 
for limits regarding various activities. 
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SECTION 3 


USER COMMANDS 


This section contains descriptions of the GCOS environment simulator user 
commands, presented in alphabetical order. Each description contains the name 
of the command (including the abbreviated form), discusses the purpose of the 
command, and shows the correct uSage. Notes and examples are included when 
necessary for clarity. 


The commands are: 


gcos, ge 
invokes GCOS batch environment simulator. 


geos card utility, gcu 
copies card image files, translating from GCOS format to ASCII or 
vice versa. 


gcos create file, gcf 
creates GCOS random files. 


gcos fms, gfms 
performs certain functions of the GCOS file management supervisor 
from Multics command level. 


gcos label tape, gelt 
writes a GCOS label on tape. 


gcos_ set environment, gse 
sets and modifies the user-controlled runtime parameters. 


gcos sySprint, gsp 
converts GCOS BCD sysout print files to ASCII files suitable for use 
with the dprint command. 


gcos sSySpunch, gspn 
converts GCOS BCD sysout punch files to files suitable for use with 
the dpunch command. 


gcos tss, gtss 
invokes GCOS time sharing environment simulator. 
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gZcos gcos 


Name: gcos, ge 


The geos command invokes the GCOS batch environment simulator to run a 
Single GCOS job in the user!s process. 


Related facilities include the GCOS daemon, which provides batch processing 
for GCOS jobs under Multics, and the gcos sysprint, gcos syspunch, and 
geos card utility commands, which may be used to manipulate GCOS format files 
that reside in the Multics storage system (these commands are described later in 
this section). More information on the simulator and the GCOS daemon may be 
found in earlier sections of this manual. 


Usage 
gcos job deck path {-control args} 


where: 


1. job deck path 

~ is the pathname of a file (segment or multisegment file) containing 
a GCOS job deck. The file may contain ASCII lines (as produced by 
one of the Multics editors) representing card images; or it may be a 
GCOS standard system format file, containing BCD and binary card 
images. It is assumed to contain ASCII lines unless the GCOS format 
is specified. One way of specifying GCOS format is tc have the name 
of the file end with the gcos suffix. The other way is the -gcos 
control argument, described below. 


2. control args 
may be chosen from the following control arguments. They may appear 
in any order and may precede or follow the job_deck_path. 


Control arguments specifying the input supplied to the simulator are: 


-ascii, -aci 
the input file contains ASCII lines, as produced by one of the Multics 
editors. This is the default, but this argument may be used if the 
name of an ASCII file ends with the suffix geos (to avoid the necessity 
of renaming the file). 


-gcos, -gc 
the input file is in GCOS standard system format, containing BCD and 
binary card images. Such a file could have been produced as output 
of a previous GCOS job, or by the gcos card utility command. 


-no canonicalize, -nocan 

~ may be used to save processing time when an ASCII input file contains 
no tab characters, and the fields on all the card images are aligned 
in the columns required by GCOS. Normally, an ASCII input file may 
contain tabs separating the fields on each line. The process of 
replacing these tabs by the appropriate number of blanks to align 
the fields in the columns required by GCOS is known as canonicalization. 
Logical tab stops are known for GCOS $ control cards and for all the 
languages supported by the simulator. See Section 2 of this manual 
for more information on canonicalization. 
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-trunecate, -te 


if any ASCII input file (the job deck file, or any ¢ SELECTed file) 
contains lines longer than 80 characters (after canonicalization), 
the extra characters are assumed to be part of comments, and are 
discarded without warning. If this argument is not given, the first 


_ Tine Tonger than 80 characters causes the job to be rejected... 


Control arguments specifying the disposition of output from the simulator 


are: 


-dprint, -dp 


queue the converted print files for printing by the Multics I/0 
daemon, followed by deletion. (The -list argument is implied and 
need not be given.) 


-dprint options "options", -dpo "options" 


queue the converted print files for printing by the I/0 daemon, but 
use the dprint control arguments supplied in the options string instead 
of the default of -delete. The options must be enclosed in quotation 
marks if they contain blanks or other delimiter characters recognized 
by the command processor. The dprint command is called via cu_$cp 
so that a user-defined abbreviation for dprint (that supplies default 
heading and destination arguments, for example) would be used in 
this call. (The -list and -dprint arguments are implied and need 
not be given.) . 


-dpunch, -dpn 


queue the converted punch files for punching by the I/O daemon in 
raw mode, followed by deletion. (The -raw argument is implied and 
need not be given.) 


~dpunch options "options", -dpno "options" 


queue the converted punch files for punching by the I/O daemon, but 
use the dpunch control arguments supplied in the options string. 
The -raw argument is always used for dpunch, since the converted 
punch files are not suitable for punching in any other mode. The 
explanations under -dprint options above, regarding quotation marks 
and abbreviations, apply to this argument as well. (The -raw and 
-dpunch arguments are implied and need not be given.) 


-hold, -hd 


do not perform the default conversion and daemon output of print and 
punch files. The default is: 


-dpo -dl -dpno "-dl -raw" 


Since the default for each file type (print or punch) is overridden 
when any of the above arguments is specified for the given file 
type, the ~hold argument is only required when one of the file types 
is to be left in GCOS standard system format., with no eonversion or 
daemon output being performed. 


-list, -ls 


convert print files (both SYSOUT and simulated printer) from BCD to 
ASCII and delete the BCD copy. (This conversion is performed by a 
call to the gcos sysprint command for each file.) 


-lower case, -le 


-raw 


translate alphabetic BCD characters in print files to lowercase ASCII. 
(Default is uppercase) 


eonvert punch files (both SYSOUT and simulated card punch) from BCD 
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(or binary) to an internal format suitable for punching by the Multics 
I/O daemon in raw mode (960 bits per card image) and delete the BCD 
copy. (This conversion is performed by a call to the gcos syspunch 
command for each file.) 


Control arguments governing the creation and use of files by the simulator 
are: 


-job id id, -id id 
“use the job identification specified by id in the names of files 
created by the simulator for this job. See Section 2 of this manual 
for more information on the naming of files. The id may be any 
character string up to 18 characters to be used in file names, or it 
may be one of the following control arguments: 


-unique 
use a Multics unique name as the job id. (A unique name is a 
15-character string, generated by the unique chars’ subroutine, 
beginning with an exclamation point and guaranteed to be unique 
within the system.) 


-jd_ seg, -jd 
use the entryname of the job deck segment as the job id. If 
the entryname ends with gcos, that suffix is removed from the 
id. (Default) 


-syot dir path, -sd path 
use the pathname of a directory specified by path for the GCOS format 
copies of print, punch, and sysout files. By default, the working 
directory is used. (The converted copies of these files are always 
placed in the working directory.) 


-temp dir path, -td path 
use the pathname of a directory specified by path for temporary GCOS 
files. (Default is the process directory) 


Other control arguments are: 
-parameter STRs, -pm STRs 
where STR strings override GCOS JCL parameter values specified on 
the $ PARAM card (i.e., specify the #n values in the JCL input). 
For example: 


jJob_deck: (in segment tape copy) 


$ snumb joba 

$ ident apert,name 

$ param »99999 

$ utility 

$ tapeg 01,x1d,,#1,,data-orig,,den8 -noring 
$ tape9 02,x2d,,#2,,data-copy,,deni16 

$ futil 01,02,copy/1f/ 

$ endjob 


Multics commands: 
gcos tape copy -1s -pm X2753 


copies tape X2753 to a scratch tape. 
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geos tape copy -1sS -pm X2753 X2754 
copies tape X2753 to tape X2754. 


Null parameters may be specified in the command with "". Parameters 
beginning with "-~" must be preceded with -string. For example, to 

specify that..parameter 1 is--equal to "X2753" and parameter 3 is 
equal to "-copy", enter: 


gcos tape copy -pm X2753 "" -string -copy 


-brief, -bf 
suppresses the printing of all terminal output produced by the simulator 
except for fatal error messages. Output from the slave program is 
not suppressed. 


-continue, ~ctu 
continues processing of the job when a nonfatal error occurs. Unless 
the -brief control argument is given, a warning message is printed 
on the user's terminal. If this argument is not given, the first 
nonfatal error causes the job to be rejected. Nonfatal errors occur 
mainly in control card processing, and are described in detail in 
Section 5. 


-debug, -db 
invokes interactive debugging aid to be used in the Multics environment 
(refer to the debug command in the Commands manual). Normally, 
unrecoverable errors cause an immediate abort of the current function 
and a reset to command level. Use of this control argument causes 
batch to call the debugging tool for further analysis of the problem 
and possible correction. 


-long, -lg 
requests certain lines from the execution report, including the begin 
and end activity lines (containing program switch word, etc.) to be 
printed in addition to the normal terminal output. 


-userlib 
enables the use of GCOS slave software libraries supplied by the 
user, instead of, or in addition to, the copies of the libraries 


installed in the system. The use of this argument is described in 
Section 2 under "GCOS Software Data Bases." 


Notes 


If no control arguments are given, the defaults are such that the command: 

geos path 
is equivalent to the command: 

gcos path -aci -dpo -dl -dpno "-dl -raw" -~-id -jd 

Any $TAPE control card in the job deck issues a mount message (to the 
operator) for the designated tape. The mount message requests insertion of a 
write ring in the tape reel unless the -noring or -nr control is included as a 


comment on the $TAPE card (see the job deck example included in the -parameter 
control argument above). 
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For tape processing, the simulator assigns drive numbers according to the 
order in which tape devices are requested. These numbers are used in reporting 
information to the caller and have no correspondence to the tape unit identifiers 
used by Multics. 


When tape density of 1600 or less is specified, and a tape drive capable of 
both 1600 and 6250 bpi is used, difficulties with tape processing may occur. 
The problem can be circumvented by using the Multics assign resource command to 
request a tape drive (i.e., one that does not support both 1600 and 6250 bpi). 
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Name: gcos card utility, geu 


The geos card utility command copies GCOS card image files, altering their 
format, content, and medium, as specified by the user. The command can make a 
partial copy of an input file, separate the input file into several output 
files, or combine several input files into one output file. te oo 


The acceptable formats are: Multics ASCII (as produced by Multics editors); 
GCOS standard system format (SSF) (defined in the File and Record Control manual); 
or raw (one of the formats used by the Multics I/0 daemon for card input and 
output). GCOS SSF or raw format files can contain compressed source decks (COMDK) 
(described under "RDREC" in the above-referenced manual). 


The contents of the files may include: one or more complete GCOS jobs 
(IMCV); one or more source or object decks (in the format produced by the GCOS 
source/object library editor); binary card images; or any other card images 
(partial GCOS jobs) subject to certain restrictions. 


The medium may be magnetic tape or a segment or multisegment file in the 
Multies storage system. 


Usage 
gcu input_specification output_specification 


The two specifications may appear in either order. The first must be completed 
before the second is begun. They consist of pathnames (or tape numbers) and 
control arguments specifying format, content, medium, partial copying, and the 
amount of information that should be printed on the uSer's terminal. 


The arguments that can be used in the specifications are described below. 
Some are meaningful only for input or for output; others have slightly different 
meanings for input and output. These restrictions are noted in the argument 
descriptions. 


A group of arguments, preceded by certain control arguments, is defined to 
be a list. A list must follow several of the control arguments described below. 
The format of a list is described below, under "Input and Output Lists." 


The argument descriptions should be read sequentially for a petter understanding 
of the operation of the command. The meanings of, and restrictions on, combinations 
of arguments are mentioned in the descriptions themselves, if they fit the context. 
Otherwise, they are mentioned later in the "Notes" portion of this command. In 
addition, some examples are given at the end of this command description. 


Except where otherwise noted, the arguments within the input and output 
specifications may appear in any order. 
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Input and Output Specifications 


The following control arguments are used to signify the beginning of the 
input or output specifications: 


~input, -in 
Signifies the beginning of the input specification. It may be omitted 
if the input specification appears first, and the input consists of 
a single file, and the pathname of that file is the first item of 
the input specification (i.e., if the pathname of the single input 
file is the first argument of the command). 


-output, -out 

signifies the beginning of the output specification. It may be omitted 
if the output specification is second, and the output consists of a 
Single file, and the pathname of that file is the first item of the 
output specification, and the input specification does not end with 
a list (i.e., if the pathname of the single output file can be 
recognized as such, thus ending the input specification and beginning 
the output specification). 


Pathname 


The following argument is used to specify an input or output file in the 
Muitics storage system: 


path 
the relative or absolute pathname of an input or output file. If 
the entry portion of the pathname ends with any of the suffixes 
ascii, gcos, raw, or comdk, it is interpreted as having the same 
meaning as the corresponding control argument (-ascii, -gceosS, -raw, 
or -comdk). 


A conflict between a suffix and a control argument is treated as an error, 
unless the control argument precedes the pathname, in which case the control 
argument overrides the suffix. This allows a file whose format does not match 
its suffix to be processed without having to be renamed first. 


For multiple file input (or output), the format of the input (or output) 
files must be the same. If the format is not specified by a control argument 
(which must precede the entire list if the pathnames have suffixes), the suffixes 
determine the format, and they must be consistent. 


The star and equal conventions may not be uSed in the pathname argument. 
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The fo 


and outpu 


llowing control arguments are used to specify the format of the input 
files: 
~aseii, -aci . 

Input and output: 


indicates that the file is in Multics ASCII format, as produced by 
one of the Multics editors. The lines are of variable length and 
end with the ASCII newline character. 


Input: 


no canonicalization of the input lines is performed unless specifically 
requested by the -canonicalize control argument. If canonicalization 
is requested, the logical tabstops must be determinable from context 
or be given with the -tabs control argument (described below). If 
the file is to be translated to BCD, it can contain only those ASCII 
characters that have BCD equivalents. 


Output: 


binary input card images are discarded. A warning message is printed 
for each contiguous group of card images discarded, giving the size 
of the group. If the input is BCD, an ASCII newline character is - 
appended to each translated BCD card image, resulting in ASCII output 
lines of 81 characters each. (See the -truncate control argument 
below.) 


-comdk, -cdk 
Input: 


indicates that if any COMDKs are present in the input file, they are 
to be decompressed. (This does not require that any COMDKs be present.) 
If this argument is not given, COMDK cards are treated as binary 
ecards, which are copied unchanged if the output format is GCOS or 
raw, but discarded if the output format is ASCII. 


Output: 


indicates that all cards except binary cards and dollar cards (GCOS 
control ecards that have a "$" in column 1) are to be compressed 
before being written in the output file. 


This control argument is designed to compress individual source decks, 
and may produce unusable results if run on complete jobs, since 
there are some nondollar cards that GCOS slave programs do not expect 
co be compressed. 


Input and output: 

only GCOS and raw format files may contain COMDKs. If raw format is 
not specified, GCOS format is assumed (and need not be specified 
explicitly) for a file containing COMDKs. 


~gcos, ~ge 
Input and output: 


indicates that the file is in GCOS standard system format. It contains 
320-word blocks (320 or fewer, for tape). Blocks begin with a block 
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control word (BCW) and contain variable length records, each beginning 
with a record control word (RCW). The records may contain BCD or 
binary card images, or ASCII lines (media codes 1, 2, or 6). 


-gcos ascii, -gca 


Output only: 


indicates that the output file is written in GCOS standard system 
format, but the records contain ASCII characters (media code 6) and 
are of varying length. Trailing new lines are removed, and any 
unused characters in the last word are filled with ASCII PAD (octal 
177) characters. 


-gcos_bed, -gceb 


Output only: 


indicates that the output file is written in GCOS BCD format. 


-no canonicalize, -ncan 


-raw 


ASCII input only: 


indicates that canonicalization should not be performed. (Default 
on all ASCII input files) 


ASCII card images may be typed in free format, with tabs separating 
fields. Canonicalization is the process of replacing the tabs with - 
the correct number of spaces to align the fields in the columns 
required by GCOS. Logical tabstops are known for dollar cards (columns 
8, 16, and 32) and for all of the languages supported by the GCOS 
environment simulator. 


If the card images contain no tabs, processing time can be saved by 
omitting the canonicalization. 


Input and output: 


specifies that the file contains card images, in the format produced 
(and accepted) by the Multics I/0 daemon, for card input (and output) 
in raw mode. Each card image is a 960-bit string, 12 rows by 80 
columns, with each 12-bit string representing the punches in one 
column, a"1i"b signifying a punched hole. 


The actual reading and punching of cards is not done by this command. 
See the description of the dpunch command in this document and the 
"Bulk Input and Output" description in the Programmer's Reference 
manual for information on card input and output. 


-tabs tabstops 


ASCII input only: 


used to supply logical tabstops to be used for canonicalization. A 
list of from 1 to 10 column numbers, in increasing numerical order, 
separated by spaces, must follow this argument. 


Normally, the set of logical tabstops to be used for each group of 
nondollar cards is determined from the system call card (e.g., $ FORTRAN, 
$ GMAP) that precedes them. If the input file contains nondollar 
cards not preceded by a system call card and canonicalization is in 
effect (-canonicalize is specified), the tabstops must be supplied 
with the -tabs control argument. When they are supplied this way, 
they are used for all nondollar cards in the file instead of the 
tabstops implied by any system call cards in the file. 
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-truncate, -te 
ASCII input: 


indicates that ASCII input lines might be longer than 80 characters 
(after canonicalization, if it is being performed), and that any 
such lines are to be truncated to 80 characters without warning. 


In the absence of this argument, the first occurrence of an ASCII 
line longer than 80 characters causes the command to be aborted. 


ASCII Output: 


trailing blanks are removed from ASCII output lines, resulting in 
lines of varying length, 81 characters or shorter, including NL. 


The format of the input or output files can be specified explicitly by one 
of the above control arguments (with the exception of -comdk), or by a suffix on 
the pathname. It may also be implied by some other argument or combinations of 
arguments, such as specifying -tape or specifying -comdk and not -raw, both of 
which imply -gcos. In the absence of any indication to the contrary, ASCII 
format is assumed. 


Only one of the above control arguments (-ascii, -gcos, -gcos ascii, -gcos bed, 
or -raw) may be used in one I/O specification. The control arguments 
(-no_canonicalize, -tabs, and -truncate) may be used only for an ASCII file. 


File Contents 


1€ following control arguments are uSed to specify the content of the 
input and output files: 


~imev list 
Input only: 


Specifies that the input file contains several complete GCOS jobs 
that are to be separated, either to copy each into a separate output 
file, or to select a subset of all the jobs for copying. 


This argument must be followed by one or more arguments specifying 
the snumbs of the jobs to be copied. The format of this list of 
Snumbs is described below under "Input and Output Lists." 


-library list, -lib list 
Input only: 


specifies that the input file contains several source or object decks, 
each preceded by a ‘$ GMAP, $ 355MAP, or $ OBJECT card with the 
four-character edit name in columns 73-76 (the format produced by 
the GCOS source/object library editor), and that the decks are to be 
Separated, either to copy each into a separate output file, or to 
Select a subset of all the decks for copying. 


This argument must be followed by one or more arguments specifying 


the edit names of the source decks to be copied. The format of this 
list of edit names is described below under "Input and Output Lists." 
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Only one of these control arguments (-imev or -library) may be used in an 
I/O specification. 


Tape Files 


The following control arguments are used when the medium of the input or 
output file is tape: 


-attached, -att 
may be used instead of a tape number, to indicate that the tape 
remains attached from a previous use of this command. Multifile 
reels may be read or written by using this command repeatedly and 
keeping the tape attached between uses with the -retain argument. 


This argument may also follow (not necessarily immediately) the tape 
number, so that the number of an attached tape can be supplied for 
writing in the label. 


-detach, -det 
detaches a tape that was retained by a previous use of this command. 
There are two uses: 


e If it is the only argument on the command line, any previously 
retained tapes, either input or output, are detached, and no 
other processing takes place. 


e If it is used within an input (or output) specification, any 
previously retained input (or output) tape is detached, allowing 
a different input (or output) tape to be attached. 


-label label, -lbl label 
used to select a file from a multifile input tape and to specify 
position and file name for an output tape. Use of this argument is 
optional. label has three possible formats: 


n 
file name 
n,file name 


where n is the position of the file on the tape to be read or 
written and file name is the 12-character name to be found (or written) 
in words 9-10 of the tape label. 


On input, if -label is not given, or on output, if n is not given, 
current tape position is assumed. The tape is positioned at its 
beginning, except for tapes that are retained from previous activities. 
(The -label control argument should not be given for a retained 
input tape that is positioned correctly, since it causes the tape to 
be rewound and searched from the beginning for the specified position 
or file name. An output tape remains positioned if only the file name 
is given, but is rewound if the position is given.) _ 


If both n and file name are given on input, and file name does not 
match words 9-10 of the nth label, the user is given the option to 
quit or continue. 

If file name is not given on output, words 9-10 are set to blanks. 
If file _name is the string -no_labels or -nl, then label processing 
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is omitted and every record read or written is treated as qa data 
record. 


-retain, -ret 
specifies that the tape is to remain attached, and positioned at the 
end of the file read or written, when the command finishes. It.is. 
then available to subsequent uses of this command without requiring 
the operator to mount and dismount it repeatedly. This argument 
must be given in each use of the command except the last, to keep 
the tape mounted. 


-tape tape number, -tape/7 tape number, -tape9 tape number 
Input and output: 


specifies a GCOS magnetic tape as input or output. For -tape the 
installation default number of tracks is used. For all three, the 
installation default density (for the given number of tracks) is 
used, unless density is specified in tape number (e.g., "-tape9 
12345,den=1600"). ~ 


One of these -tape control arguments must precede the -retain and 
-label control arguments, if they are given. 


The tape is assumed to. be labeled with standard GCOS labels, as 
described in the File and Record Control manual. (See -no_ labels 
under the -label control argument below.) Multifile reels are 
Supported, but only as described below. Multireel files are not 
Supported. 


tape number is the tape reel serial number (word four of the label). 
It may be up to five characters long. It is used in the mount 
message to the Multics operator and written in the header label, for 
output. 


Only GCOS format files can be read from or written onto tape; the -gcos 
control argument is implied and need not be given. 


If a tape file is specified for input (or output), it must be the only 
input (or output) file specified. 


Partial Copying 


The following control arguments may be used to specify that a subset of the 
card images in each input file should be copied: 


-count N, -ct N 
where N is the number of card images to be copied. 


-first N, -ft N 
where N is the number of the first card image to be copied. 


-last N, -1t N 
where N is the number of the last card image to be copied. 


Counting is performed on card images sent to the output file, but before 
they are compressed, if COMDK output was specified. Input card images have 
already been decompressed, and binary card images discarded for ASCII output, 
before counting takes place. 
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If -first is not given, copying begins with the first card image. If 
neither -last nor -count is given, copying proceeds to the end of the file. The 
-last and -count control arguments may not both be used in the same specification. 


For IMCV or library content, only the specified subset is searched for the 
jobs or decks to be copied,: and copying stops in the middle of a job or deck if 
the end of the subset is reached. Also, COMDKs that are not being copied are 
not decompressed, so COMDK card images, rather than decompressed card images, 
are counted during the search for the next job or deck to be copied. 


Output File Name Duplication 


The following control argument may be used to specify the action to be 
taken when the output file already exists: 


-append, -app 
Output (nontape) only: 


specifies that, if an output file already exists, the output is to 
be appended to it, immediately following its current contents. The 
format of the existing file must be the same as that of the output 
to be written. If it is not, the results are unpredictable. 


If this argument is not given, and the output file already exists, 
the user is given the choice of aborting the command, or deleting 
the existing file and continuing. 


Input and Output Lists 


The following arguments are used to specify a list of Multics files, or of 
jobs or decks within a single file, to be copied: 


-all 
Input only: 


may follow -imev or -library to indicate that the entire contents of 
the input file are to be copied, each job or deck into a Separate 
output file. 


-file input path, -file path, -fi path 
Input and output: 


path is the pathname of a segment containing the file names, or 
Snumbs, or edit names, one name per line. This form may be used 
(after -list, -imev, or -library) when the list of names is long and 
inconvenient to type on the command line. 
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List 
Input and output: 


specifies a list of Multiecs files to be copied from or into. The 
list that follows it has the same format as the lists after -imcv or 
~gmap, except that -all cannot be included in it. 


-name, -nm 
Output only: 


may follow -iist to indicate that the names of output files should 
be taken from the snumbs or edit names of jobs or decks from an IMCV 
or library input file. The output files are placed in the working 
directory and have entrynames of the form snumb.suffix or 
edit name.suffix, where suffix is ascii, geos, or raw, depending on 
the format of the output file. 


name 1 eos Namen 
Input and output: 


names of input output files, input snumbs, or input edit names may 
be given on the command line, after -list, -imev, or -library. 


Terminal Output 


The following control arguments are used to specify the amount of information 
to be printed on the user's terminal: 


-brief, -bf 
t 


Input and out 


. 
utput: 


debe eM 
specifies that messages warning of nonfatal errors, or giving detailed 
information about errors, should not be printed on the terminal. 
The argument may be used in both the input and output specifications, 
to suppress messages connected with the reading of input or the 


writing of output. 


-debug, -db 


Input or output: 


may be given once on the command line, in either the input or the 
cutput specification. Its meaning is independent of its location. 
It indicates that whenever an error occurs, the Multics debug command 
(see the Commands manual) is to be called after the error message is 
printed, giving the user the opportunity to determine the cause of 
the error and possibly correct it and cause processing to continue. 


~long, -lg 
Input: 


specifies that the names of input items (snumbs, edit names, tape 
file names, Multics pathnames) be printed on the terminal as they 
are read from input. 

Output: 


specifies that the names of items selected for copying be printed on 
the terminal as they are written to output. 
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Input and output: 


if this argument is given for both input and output, all input item 
names are printed, and those selected for copying are so indicated. 


This argument is not inconsistent with -brief. The two arguments 
control the printing of different types of information, and both may 
be given on the same command line. 


Notes 


Only one of the control arguments specifying a list of items (-list, -imev, 
or -library) may be given in an input or output specification. The items can be 
file names, snumbs, or edit names. 


If a list of output file names is given, and the number of input items does 
not match the number of output file names, copying proceeds until one of the 
lists is exhausted, and then a warning message is printed on the terminal. 


When a list of snumbs or edit names is given, the input file is read 
sequentially and the list is searched for a match with each snumb or edit name 
in the input file to determine whether the job or deck should be copied. Thus 
the order of items in the output file is the same as their order in the input 
file, and the order of the list is not significant. However, a list of input 
(or output) file names is read (or written) in the order in which they appear in 
the list. 


Alphabetic BCD input is translated to lowercase ASCII. Arguments containing 
edit names, tape labels, etc., must be typed in lowercase in order to compare 
with corresponding BCD names from the input file. 


Examples 


To convert the Multics ASCII segment named readable.jel into a GCOS BCD card 
image file named GJOB utilizing canonicalization and tab stops at 8, 16, and 32, 
enter: 

gcu readable.jcl -ascii -can -tabs 8 16 32 -out GJOB -gceos bed 


To convert the GCOS TSS formatted file named SPCWRS into a Multics ASCII 
segment, enter: 


gcu SPCWRS -gcos space _wars.fortran 


To extract the source program named TSSA from the GCOS 800-bpi tape U8421 
which is a library of COMDKs (a K* tape), enter: 


gcu -in -tape u8421 -comdk -lib tssa -out tssa.ascii 


To convert the GCOS BCD file named pswdlst.gcos to a Multics ASCII text 
file, enter: 


gcu pswdlst.geos password.list.ascii 
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ee me 


To copy a BCD file contained in the GCOS 1600-bpi tape identified as 12D0 [ 
to a Multics ASCII text file called gcos manuals, enter: 


gcu -input -tape 12do,den=1600 -output gcos manuals -ascii 
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gcos create file gcos create file 
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Name: gcos create file, gcf 


The gcos create file command is used to create files that are compatible 
with GCOS random filés. 


Usage 


gef filename {-control arg} 


where: 
1. filename 

is the Multics pathname of the GCOS file. 
2. control arg 


may be either -links N or -llinks N (where N is the file size in 
either links or llinks). (Default is -llinks 1) 


Note 


This command is used when a GCOS job (or activity) requires space in the 
form of a random file. The gcos create file command must be used to create the 
random file before the GCOS fob is executed. 
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gcos fms gcos fms 


Name: gceos fms, gfms 


mm 1 a Punn - QO A TPH ma rH Qa trp - 
The geos fms command unloads files from a GCOS MASTER or USER SAVE tape. 


This provides | a convenient means of transporting files to be used with the 
Multics GCOS simulator (gcos and gtss comands) from a GCOS environment. Multics 


directory. hierarchy.is created,.along with any segments or muliti-segment files, 


to contain the GCOS catalog structure. 


Usage 
gfme reel number {-control args} 


where: 


1. reel number 
is the tape reel identifier for the input save tape and is in the 
form of a string of alphanumeric characters (e.g., AAAAA). 


26 control args 
ean be chosen from the following: 


-control file path, -cf path 
path specifies the pathname of a Multics segment containing a list 
of (only) those GCOS user names whose files are to be unloaded. The 
contents of this segment are in free-form format as: 


restorelist: user_namel {, user name2}... ; 


-density WN, -den N 
N specifies tape density as 200, 556, 800, 1600, or 6250. 


-directory mapping rule name, -drm rule name 
establishes the directory mapping rule for the restore process. The 
rule name should be entered as "ume", "sme", or "wd". If sme is 
selected, then the control arg "-sme pathname path" must also be 
supplied. (See "Notes" below.) (Default is wd) 


-no acl 
“ prevents the ACL for the segment containing the GCOS files from 
being determined from the permission information on the SAVE TAPE. 
This ACL information is usually unrelated to Multics ACLs. 


-restore umc_name, -rest umc_name 
restores GCOS catalog structure identified by umc name (user master 
catalog name). The eer aul is obtained from the catalog on the 
tape. (See "Notes" below. 


~Smc_pathname path, -spn path 
establishes the pathname for sme directory mapping if the 
-directory mapping sme argument is supplied. 


-track N, -tk N 
N is either "7" or "9" to specify 7- or 9-track tape. (If the track 
argument is not included, the system Defaults to 9-track.) 
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Notes 


If the SAVE tape format is unknown, an invocation of gcos fms reel number 
attempts to determine tape density and the SAVE tape (MASTER or USER) USER ID, 
and uses the current working directory as the default area in which to unload 
the contents of the specified SAVE tape. Error messages are output if tne tape 
cannot be processed. 


The restored structure is placed in the Multics storage system depending on 
the option given with the -directory mapping argument. If the mapping rule is 
ume, the initial catalog (UMC) is placed beneath the directory ">udd>ume name", 
where umc name represents the name given after the -restore argument. Thus all 
subordinate structures are placed under the directory ">udd>umc name>umec name". 
If the mapping rule is smc, the UMC catalog is placed immediately under the 
directory named with the -sme pathname argument. If the mapping rule is wd, the 
current working directory is taken to be synonymous with the UMC catalog. Ail 
subordinate structure is placed below the working directory. 


The user process must have sma access to the directory below which the 
restore is to be done. For a restore with mapping rule "ume", this usually 
requires the cooperation of the System Administrator to either create the directory 
>udd>user_name, or to add the name user _name to an existing project. 


The gcos fms program does not currently restore permissions or other individual 
attributes of catalogs or files. 


If multiple occurrences of any of the control arguments -track, -restore, 
-directory mapping, or ~-smc_ pathname appear in the same command line, the last 
occurrence of the respective control argument is used. 


Attempting to unload a very large number of files may cause the known 
segment table (KST) to overflow. Three choices of action are available should 
this condition occur: request the project administrator to increase the size of 
the KST; break the request down into several partial saves of GCOS files (DOONLYs 
or catalog saves); have the GCOS site administrator restore the GCOS userid on 
the GCOS system from a MASTER SAVE tape and re-create the save tape. 
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Name: gcos label tape, gelt 


The geos label tape command writes a GCOS label on a tape. | 
Usage . 

gcelt reel num {new_num} {-control args} 
where: 


1s reel num 
is the number on the label of the tape reel to be used. 


2a new num 
Same aS the reel num, it may be omitted. 


3% control args 
can be chosen from the following: 


-density N, -den N 
where N specifies the tape density. (Default is 1600 bpi) 


-erase 
erases the tape before labeling it. Default is to overwrite the 
label (if it exists), and leave the remaining data intact. 


is the new serial number to be written on the tape. If it is the 
old 


-no erase 
does not erase the tape before labeling it. (Default) 


-track N, -tk N 
where N specifies 7- or 9-track tape. (Default is 9-track) 


Notes 


If no control arguments are given, the command: 
gelt xyzle 

is equivalent to the command: 
gelt xyz12 xyz12 -tk 9 -den 1600 -no_erase 


If conflicting control arguments are given, the rightmost control argument 
is used (e.g., "gelt m1266 -tk 7 -tk 9" results in a 9-track tape label.) 
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Name: gcos set environment, gse 


This command may be given in the user's process before the gcos tss command 
is invoked, to modify the user-controlled run-time parameters for GTSS. 
Usage 


gse {-control args} 


where control args may be chosen from the following control arguments: 


-directory mapping mapping rule, -drm mapping rule 
sets the directory mapping to use the specified mapping rule. The 
following mapping rules are allowed: umc, smc, and wd. The default 
is wd. See Section 1 for a discussion on "Mapping File Strings to 
Pathnames." 


-gcos debug pathname path, -gdbpn path 
sets the path of the control file to be used when the gcos debug 
command is invoked. (If path is not specified a Default of 
>udd>Project_id>Person_id>Person id.gdb is used.) 


-modes modes string 
sets the modes, according to modes string. Mode names are separated 
by commas, each one optionally preceded by a circumflex (*) to turn 
the specified mode off. Modes not specified in modes string are 
left unchanged. 


ast 
prints the asterisk for each input request in GTSS build mode. 
When off, no prompt character is given. (Default is on) 

drl 
prints trace information on each derail. The derail name and 
its location are printed. (Default is off) 

gdb 
gcos debug breaks are inserted in slave object code as it is 
loaded. The gcos debug command is invoked when such a break is 
encountered during execution. (Default is off) 

memd 
allows the use of the e request at GTSS command level. When 
allowed, the remainder of the input line is passed on to the 
Multics command processor. (Default is off) 

mquit 
GTSS goes to a new Multics command level in response to the quit 
(or break) key. When off, depressing the quit key on the terminal 
resets the current GCOS time sharing subsystem function and returns 
to GTSS command level. (Default is off) 

ss 


prints trace information about each subsystem call. The subsystem 
name is printed. (Default is off) 
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gcos set environment gcos set_environment 


=print, ~pr 
displays on the user output switch the current control information 


set by this command. If there are multiple control arguments, -print 
is the last one processed 


~reset, -rs 
sets all modes to the default. 


-sme pathname path, -spn path 
“sets path as the root directory to be used when catalog/file strings 
are mapped into Multics pathnames using the system master catalog 
(SMC) directory mapping rule. This control argument is required 
when -directory mapping sme is specified. 


-ume name name, -unm name 

“sets the user master catalog (UMC) name to be used for catalog/file 
String operations where UMC name is only implied. Name may be given 
in upper or lowercase, but otherwise is equivalent to the user's 
GCOS login USERID. This control argument is required when 
-directory mapping ume or -directory mapping sme is specified. The 
UMC name is mapped to lowercase for use in constructing Multics 
pathnames. 


Notes 


The user must have at least status access to the directory implied by the 
directory mapping rule and to its containing directory. 


If any error is detected by the gceos set environment command, no changes 
are made to any of the user-controlled runtime parameters. 
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Name: gcos_sysprint, gsp 


The gcos sysprint command converts a print file (either SYSOUT or simulated 
printer) produced by the GCOS environment simulator from GCOS ASCII or BCD to 
Multics ASCII for printing or viewing on a terminal. This command is called 
automatically by the simulator to convert any print files produced by the job, 
unless the -hold option is given on the gcos command line. It can also be 
called by the user to convert a file that was not converted automatically. 


Usage 
gsp input _path {output_path} {-control_ arg} 


where: 


1. input_path 
is the pathname of a print file produced by the simulator. 


2s output path 
“is the pathname of a file into which the ASCII output lines are to 
be written. If the file already exists, it is overwritten with no 
warning. If output path is omitted, the lines are displayed on the 
user's terminal as they are converted. 


be control arg 
-lower case, -le 
translates alphabetic characters to lowercase ASCII. (Default is 
uppercase) 
Notes 


The star and equal conventions are not implemented in this command. 


If tne first record in the file is the SYSOUT header record written by the 
Simulator, then the records are ordered by report code (within each activity) 
before being printed, and all records from the execution report are printed 
first. Otherwise the records are printed in the order in which they appear in 
the input file, with no sorting or reordering of any kind. 


The records are assumed to be GCOS print line images, ending with GCOS 
printer control characters. These latter are converted to ASCII newline and 
newpage characters. To convert a BCD card image file to ASCII, with newline 
characters being added to the end of each line, use the gcos card_utility command. 
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Name: gcos_ syspunch, gspn 


monn 


The goos syspunch command converts a GCOS standard system format file containing 
BCD and binary card images to a format suitable for punching using the Multics 
dpunch command with the -raw argument. This command is called automatically by 
the GCOS environment simulator..to convert any punch files produced by the job, 
unless the -hold argument is given on the gcos command line. It can also be 
called by the user to convert any GCOS card image file for dpunching. 


Usage 
gspn path 


where path is the pathname of the card image file to be converted. 


Notes 


The output is written into a segment in the working directory whose entryname 
consists of the entryname portion of path plus the suffix raw. If this segment 
already exists, it will be overwritten with no warning. 


The star convention is not implemented in this command. 


The conversion produces a 960-bit string for each input card image. Each 
j2-bit string represents one of the 80 card columns, with a 11-bit indicating 
that a hole should be punched in the corresponding row and column. This conversion 
is such that, when the output file is punched using the dpunch -raw command, the 
result is valid GCOS BCD or binary cards containing the same information that 
was in the records of the input file. 
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Name: gcos tss, gtss 


The gcos tss command invokes the GTSS to run a single GCOS time sharing 
user in the user's process. 


Usage 


gtss 


Notes 


All parameters controlling the operation of geos tss are set with the 
gcos set _environment command. If gtss is invoked with no prior call to 
gcos set environment, the following values are assumed: 


-drm wd -modes ast,“drl,*gbd,*memd,*mquit, “ss 


The gtss SAVE command will not set the bit counts on segments created via 
this command, since they are not needed by the Simulator. If, however, the user 
wishes to manipulate the files via programs external to the simulator (such as 
gcos card utility), the bit counts must first be set modulo 320 words. 


The gtss command may not be invoked while the caller is using window call 
(video mode). The GTSS subsystems cannot handle the special I/0 required to 
support this terminal interface. ; 
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SECTION 4 
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MASTER MODE ENTRIES 


This section describes the differences in MME processing between native 
GCCS and the GCOS environment simulator. Complete documentation of the GCOS 
MMEs can be found in the General Comprehensive Operating Supervisor (GCOS) manual. 


OVERVIEW OF MME PROCESSING 


Every attempt is made by the simulator to process MMEs in the same manner 
as native GCOS. Since the level 68 hardware is a superset of the level 66 
hardware, the hardware mechanisms for MME processing are identical. The only 
differences that may exist, therefore, are due to features of some MMEs that are 
not yet supported by the simulator. 


Whenever a MME (op eode = 001 octal) is executed by the slave job, a fault 
is signalled in the user ring. The simulator, before starting an activity execution, 
sets up a static handler for processing this fault. When the fault is signalled, 
the simulator's MME processor is called and simulation of native GCOS actions 
begin. 


Bata ™ 


Once the MME processor is in controi, it extracts the address from the 
faulting instruction and uses it to index a table of MME processing subroutines. 
The appropriate subroutine is called and the MME simulation is carried out. 
When this simulation is completed, control returns to the MME processor which 
restarts the slave job. 


MME DIFFERENCES 


-EMM - is not supported 


GEBORT - is supported 
including the storing of appropriate data in the slave prefix. Also, due 
to the fact that all I/0 is performed time-sequential, no user I/0 is lost. 


GECALL - is supported 
as if the simulated GCOS system had no production library. 


GECHEK - is supported as qualified. 
processed as if the requested checkpoint dump was successful. However, no 
checkpoint dump is written to the specified file. 


GEENDC - is supported 


GEFADD - is supported as qualified 
1. All physical device addresses are manufactured by the GCOS environment. 
2. ASCII and 51-column capabilities are not provided for card punches. 
3. ASCII capability is not available for printers. 
4. All fields are returned for mass storage files and tapes. 
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GEFCON - is supported 
notice that the physical device address is a simulated value as with the GEFADD 
MME. 


GEFILS - is not supported 
execution of this MME causes the slave activity to abort. 


GEFINI - is supported 


GEFRCE - is supported as qualified ; 
the undocumented interfaces for UFAS are not supported. 


GEFSYE - is supported as qualified 
functions: 2 catalog create; 3 file create; 9 file release; and 22 file purge. 


GEIDSE - is supported as qualified 
execution of this MME is allowed for the I-D-S/I open function. The open 
information always indicates that disk accounting is used and that no special FMS 
funetions are provided. 


GEINFO - is supported as qualified 
1. SSA copying of the first two words only is supported. 
2. Requesting a program number for a SNUMB other than the current job's 
SNUMB causes an abort of the slave program. 


GEINOS - is supported as qualified 
1. The intercom facility is not supported; 


ine) 


The following list of 1/0 commands are not Supported: 


write printer (WPR, WPRC) 

write printer ASCII (WPRASC, WPRCAS, WPREAS, WPRECA) 
reread tape decimal (RRTD) 

reread tape binary (RRTB) 

set file protect (SFP) 

read EBCDIC (RTE) 

read ASCII/EBCDIC (RTAE) 

read ASCII (RTA) 

write EBCDIC (WTE) 

write ASCII/EBCDIC (WTAE) 

write ASCII (WTA) 

set file permit (SFPR) 

tape load (TPLD) 

write drum and verify (WDRV) 

drum compare and verify (DRCV) 

write disk - continuous and verify (SDICV) 
compare and verify (DICV) 

write disk - continuous and compare (WDICV) 
write disk ASCII (WDASC) 

read disk ASCII (RDASC) 

read disk nonstandard size (RDNSZ) 


GELAPS - is supported 
GELBAR - is supported 


GELOOP - is not supported 
execution of this MME causes the slave activity to abort. 


GEMORE - is supported 
see "Mapping of file Strings to Pathnames" in Section 1 for a description of 
catalog/filename to pathname mapping. 

GEMREL - is supported 

GENEWS - is not supported 
execution of this MME causes the slave activity to abort. 
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GEPRIO - is ignored 
no special action is necessary due to the time-sequential operation of all I/0 
simulation. 


GERELC - is ignored 
no special action is necessary due to the time-sequential operation of all I/0 
simulation. 

GERELS - is supported 

GERETS - is supported 

GERIAD - is ignored 
no special action is necessary due to the time-sequential operation of all I/0 
Simulation. 


GEROLL - is not supported 
execution of this MME causes the slave activity to abort. 


GEROUT - is supported as qualified 
The following operations are implemented: 


3 (octal) - direct aecess output 
4 (oetal) - direct access output, then input 
5 (octal) - user program inquiry to terminal 
6 (octal) - program requests terminal type 
17 (octal) - program requests line disconnect 
20 (octal) - direct access current line status 


All operations not implemented fall into the category of paper tape 
manipulation, line switching, extended output length, or BTT load/start 
operations. 


Output is written to the user_output stream and input is read from the user_input 
stream. Data is translated to and from the Multies standard data format. This 
allows the stream names to be associated with any type of device. The edited I/0 
mode is used for output to suppress escape printing. 


presses the appropriate key on the 
by the program_interrupt command. 


Direct access is established (if not already) on any correct call with operation 
eode 3, 4, or 5. 


GERSTR - is supported as qualified 
either native GCOS or GCOS environment simulator system format disk files may be 
used. Tape files are not supported. 


GESAVE - is supported as qualified 
the format of the system file produced is not the same as that produced by the 
GESAVE MME in native GCOS. The geos_tss command cannot read these files, it 
requires files created by native GCOS, the System Editor ($SYSEDIT), or some TSS 
subsystem in gtss. 


GESECR - is not supported 


GESETS 


is supported 
GESNAP - is supported 


GESNUM - is not supported 
execution of this MME causes the slave activity to abort. 


GESPEC - is not supported 
execution of this MME causes the slave activity to abort. 
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GESYOT - is supported as qualified 
requests for backdoor file processing are denied as if no backdoor file were 
configured. 


GETIME - is supported 


GEUSER - is supported as qualified 
execution of this MME causes a search using the Multics search rules for a 
subroutine mme_geuser. If found, this subroutine is called in the same manner as 
any of the MME processing subroutines of the GCOS environment simulator. If the 
subroutine mme_geuser is not found, the slave activity is aborted. 


GEWAKE - is not supported 


GE XLIT is not supported 


GMODER - is not supported 


GMODES 


is not supported 
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SECTION 5 


This section describes the differences in control card processing between 
native GCOS and the GCOS environment simulator. Complete documentation of the 
GCOS control ecards can be found in the Control Cards Reference Manual. 


OVERVIEW OF CONTROL CARD PROCESSING 


The simulator attempts to process valid job decks in the same manner as 
native GCOS. However, the internal functioning of the simulator differs from 
that of GCOS and some features of GCOS, and responses to incorrect jobs may not 
be the same. To assist users in coping with such differences, the card processing 
algorithm of the simulator is described in the following paragraphs. 


The simulator classifies cards into the following categories: 


nondollar (data) cards 
do not have a $ in column 1 and are never interpreted by the simulator. 
These cards usually are written to a file. 


dollar cards 
have a $ in column 1 and are completely interpreted by the simulator. 
These cards also may be written to a file (e.g., file cards being 
written to the R* file in an execute activity). 


non-GCOS dollar cards 
have a $ in column 1, but are not interpreted by the simulator. The 
ecards are written to a file for interpretation by the slave program. 
These cards include the general loader, BMC, utility, and editor 
directive cards. 


Some of the non-GCOS dollar cards cause the simulator to take some 
action in addition to writing the card to a file. However, this 
action does not involve examining the option field of the card. 


Notice that the descriptions of the non-GCOS dollar cards correspond to 
those in the supported release of native GCOS, while those of other dollar cards 
correspond to the supported release of native GCOS except where noted otherwise 
in the text of this section. This is because the non-GCOS dollar cards are 
interpreted by native GCOS siave software taken directiy from tne GCOS total 
system tape, while the other dollar cards are interpreted by the simulator. 


For each activity delimiting card, there is a default nondollar file code. 
A group of nondollar cards encountered in the activity and not preceded by a 
$ DATA card is written using this default file code provided the default file 
code is not specified explicitly within the activity. (If the default file code 
is defined explicitly the cards are discarded and a single warning message is 
issued.) The first dollar card terminates the group of nondollar cards and 
subsequent cards are not written to the file. 
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Several dollar cards cause the nondollar file code to be set to a value 
other than the default. Among these are the $ DATA, $ OBJECT, $ DUMP, and $ UPDATE 
cards. Again, the first dollar card terminates the group of nondollar cards. 
Exceptions to this are the $ DATA card with the COPY option, which must be 
terminated by a $ ENDCOPY card, and the $ UPDATE card, which is terminated by 
the first dollar card that is other than a $ ALTER card. 


The simulator refuses to write cards from the input deck onto a file that 
already exists in the activity (with the exception of writing file cards to the 
R* file in an execution activity). Such cards are discarded and a warning 
message is issued. 


If a file code is used more than once in an activity (i.e., on several file 
cards), the last file card encountered is used. When a duplicate file code is 
encountered, the previous file is closed and the new one is opened. Thus, any 
errors on the earlier file card prevent the job from running, even though the 
earlier card was replaced. 


Dollar cards that are completely unknown (stranger) to the simulator are 
printed on the execution report. If the -brief control argument is not given on 
the command line, these cards also are printed on the user's console during the 
first pass of input media conversion. 


Dollar cards that are known to be valid GCOS control cards, but which are 
not supported by the simulator, cause a nonfatal error. Execution continues 
(the card is treated as an unknown card) after a nonfatal error only if the 
-continue control argument is given on the command line. If this argument is 
not given, the job is aborted after a nonfatal error. 


Cards that are known to be BMC, utility, or editor directives that are 


encountered in the job deck in the wrong context cause a nonfatal error. 


Errors in the operand field of a dollar card (including use of unsupported 
options) cause a fatal error. The job is always aborted after a fatal error. 
Errors of this type are detected during the allocation that precedes the activity 
and not before any activities have been run (as is the case in native GCOS). 


CONTROL CARD DIFFERENCES 


$ ABORT - is supported 

$ ALGOL - is supported 

$ ALTER - is supported as qualified 
is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 

$ ASCII - is not supported 

$ ASSEM - is supported as qualified 
is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 


$ BREAK - is supported 


$ CBL74 - is supported 
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CHANGE - is supported as qualified 
is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 


CIDS2 - is supported 


COBOL - is supported 


COMMENT - is supported as qualified 
the message text is displayed on the user's terminal and not on the operator's 


eonsole. 


COMPILE ~ is supported as qualified 
is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 


CONVER - is supported 


COPY - is supported as qualified 
is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 


DAC - is supported 
processed as if it were a $ SYSOUT control ecard. 


DATA - is supported as qualified 
1. The saving of data files is not supported. 
2. The TAKEc, SEQ, CKSEQ, NSEQ, GE225, and IBMPL options are not supported. 
3. File concatenation is not supported. 


DELETE - is supported as qualified: 
is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 


DKEND - is supported 


DUMMY - is supported as qualified 
is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 


DUMP - is supported 


ENDCOPY ~- is supported as qualified 
is processed by slave software, but if control ecard is encountered out of 
context, a warning is issued on the execution report. 


ENDEDIT - is supported as qualified 
is processed by slave software, but if control card is encountered out 
context, a warning is issued on the execution report. 


.) 
a) 


ENDJOB - is supported 

ENDLD - is supported as qualified 
is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 


ENTRY - is supported 


ENX - is not supported 


#®*EOF - is supported 


$ 


EQUATE - is supported 
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ETC - is supported as qualified 
is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 


EXECUTE - is supported 
EXTEDIT - is not supported 
EXTEND - is not supported 
FFILE - is supported as qualified 
is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 
FILE -is supported as qualified 
1. Since all mass storage I/O is simulated using Multics segments, device 
type options on the $ FILE card are ignored. 
2. Creation of cataloged files or access to cataloged files via $ FILE is 
not supported. 
3. File concatenation is not supported. 
FILEDIT - is supported 
FILGP - is not supported 
FILSYS - is not supported 
FORM - is supported as qualified 
is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 
FORTRAN - is supported 
FORTY - is supported 
FORT77 - is supported 


FUTLL - is supported as qualified 
is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 


GET - is supported as qualified 
is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 

GETRWD - is supported 

GMAP - is supported 

GOTO - is supported 

IDENT - is supported as qualified 
no restrictions are enforced on the data in columns 16 through 72 and no 
accounting information is taken from the control card. Jobs submitted through 
the GCOS daemon must have the account_id registered. (See Appendix A for 
additional details.) 

IDS - is supported 


IDS2 - is supported as qualified 


1. Concurrent access control is provided on a file basis for read and 
write access types for any IDS2 data base file initialized via $ PROGRAM 
Q2UTIL. 


2. A lock control segment with the .CONCURRENCY suffix is created in the 
same directory as the IDS2 data base and must not be altered if concurrent 
access control is to be provided. 


IF - is supported 
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INCLUDE - is supported as qualified : 
is processed by slave software, but if control card is encountered out of 
eontext, a warning is issued on the execution report. 


INCODE - is supported as qualified 
the GE225 and IBMPL options are not supported. 


INPUT - is supported as qualified 
is processed by slave software, but if control ecard is encountered out of 
context, a warning is issued on the execution report. 


JOVIAL - is supported 
Label - is supported 
LIBRARY ~- is supported 
LIMITS - is supported as qualified 
1. A "P" preceding the print lines specification is ignored. 
2. The I/O time field is not processed. 
3. If NLSTOU is specified on the $ GMAP card, the default line count is 
allocated rather than 2500. 
LINK - is supported 
LIST - is supported as qualified 
is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 
LODLIB - is not supported 
LOWLOAD ~ is supported 
MODIFY ~ is supported as qualified 


is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 


MSG1, $MSG2, $MSG3, - is supported as qualified 
the message text is displayed on the user's terminal and not on the operator's 
console. 


MULTI - is supported as qualified 
is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 


NEED - is supported as qualified 
the SYS/n option is not allowed. 


NLOAD - is supported 

NOLIB - is supported 

NTAPE - is not supported 

OBJECT - is supported 

OBJLIB - iS not supported 

OPTION = is supported 

OUTPUT - is supported as qualified 
is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 

PARAM - is Supported 
the GCOS environment simulator support of the $ PARAM card allows some 
extensions to the GCOS support. These include up to 32 parameters (as 


opposed to 9 in GCOS), and "stranger options" (refer to General Comprehensive 
Operating Supervisor (GCOS) manual, Section 2). Parameters can also be 
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specified by using the -parameter control argument to the gcos command 
described in Section 3. 


PATCH - is supported as qualified 
is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 

PL1 - is supported 

PPS - is not supported 

PPSRPT - is not supported 

PPTP ~ is not supported | 

PPTR - is not supported 

PRINT ~- is supported as qualified 


it does not allocate a printer. Instead, an output collection file is used 
and is then processed as any SYSOUT file. 


$ PRIVITY - is not supported 


Ff fF Gf fF 


PRMFL - is supported as qualified 
1. rec, r/c, w/e, t, t/ce, c, and r/w/e permissions are not supported. 
2. The following extensions are included: 
a. The $ USERID card is only necessary for jobs submitted via the GCOS 
daemon. 
b. A Multics lowercase pathname may be used rather than a GCOS 
catalog/filename string on the $ PRMFL card. The file string field 
is recognized as a GCOS catalog/filename string only if it contains a 
slash (/) and does not contain either a less-than (<) or greater-than 
(>) symbol. If the file string is a Multics pathname, a greater-than 
(>) symbol can be used to indicate that a $ ETC card follows. Also 
$ PARAM argument substitutions are not made in Multics pathnames. 


3. Notice that the contents of the referenced file are assumed to be in 
GCOS format (not Mulitics ASCII) and that the -ascii argument in the 
comment field is not supported. 

4, Refer to the gcos create file command as regards random file creation. 

5. File concatenation is not supported. 


PROGRAM - is supported as qualified 
the EXTEND option however, is ignored if present. 


PSM - is not supported 

PUNCH (FILEDIT) - is supported as qualified 
is processed by slave software, but if this control card is encountered out 
of context, a warning is issued on the execution report of the user's job 
and is interpreted as a request for allocation of a card punch. 

PUNCH (GCOS) - is supported as qualified 
the punch type field is ignored. Notice that punched output is automatically 
directed to a Multics segment for the user. 

QUTIL - is supported as qualified 
is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 

READ - is not supported 

RELADD - is not supported 

RELCOM - is supported 


REMOTE - is supported as qualified 
all processing is as if the card were a $ SYSOUT control card. 
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REPORT - is not supported 


REPTL - is not supported 


REPTR - is not supported 


RPG2 - is supported 


S2PROG - is not supported 


SELECT - is supported 
the comment field (following the catalog/filename string) can contain the 


string -ascii-to- specify that the file being selected is a Multics ASCIT 


segment. 


SELECTD - is supported 
the comment field (following the catalog/filename string) can contain the 
string -ascii to specify that the file being selected is a Multics ASCII 
segment. 


SEQ - is supported as qualified 
is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 


SET - is supported 


SETSQ - is supported as qualified 
is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 


SETSQ1 


- is supported as qualified 


is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 


SNUMB - is supported 
the urgency level is ignored except when processed by the GCOS daemon. 


SOURCE - is supported 


SRCLIB - is not supported 


SYSEDIT - is supported as qualified 
Since the execution unit created is the same as native GCOS, SYSEDIT may 
not be used to create a Q* file from a file which is created in part by MME 
GESAVE. 


SYSLD - is supported as qualified 
is processed by slave software, but if control card is encountered out of 
context, a warning is issued on the execution report. 


SYSNAME - is not supported 


SYSOUT - is supported as qualified 
the destination field is ignored. 


TAPE, 


Ewihid 


$ TAPE7, $ TAPE9 ~ is supported as qualified 

Muitireei tapes are currentiy not supported by the GCOS environment 
Simulator; therefore the multireel indicator is ignored. 

The class field is ignored. 

File concatenation is not supported. 

The tape mount message issued to the operator includes a request for a 
write ring unless the card contains "-noring" or -nr" as a comment. For 
example: 


$ tape9 in,xld,, 12345, ,master_data,,den16 -nr 


requests the operator to mount tape 12345 with no write ring inserted. 


$ TAPE27, $ TAPE29 - is not supported 
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TYPE - is supported 
UPDATE - is supported 
USE - is supported 


USERID - is supported as qualified 


Since Multics security is in effect for all GCOS environment simulator 


jobs, this control card is ignored, 
GCOS daemon. 


UTILITY - is supported 
UTLe2 - is supported 

WHEN - is supported 
xxxPK - is not supported 
355MAP - is supported 


355SIM - is supported 


except for jobs submitted through the 
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SECTION 6 


GCOS TIME SHARING ENVIRONMENT SIMULATOR 


This section describes the GCOS time sharing environment simulator on Multics 
(GTSS). GTSS is intended to provide most of the functions available to a slave 
user of GCOS time sharing. 


The gcos_tss command is a Multics command, invoked from Multics command 
level. It establishes the environment for the GCOS time sharing slave software 
and is executed as is (just as though it were executing on a native GCOS system). 


The GTSS interfaces are nearly identical to those provided by native GCOS, 
Thus, the user can "log in" to GTISS by invoking the gcos_ tss command and proceed 
as if actually logged in to native GCOS time sharing. There are some differences 
in the specific terminal interfaces and also in the file system. These are 
described later in this section. 


The GTSS executive functions are performed by Multics programs, written to 
simulate the same functions provided by the native GCOS time sharing executive. 
Initially, the user is in GTSS command level, or build mode. When a command is 
entered, the executive calls in the GCOS subsystem to perform that function. 


This is done by setting the object programs into execution in GCOS BAR 
mode. When the slave program executes a derail instruction for services by the 
GCOS time sharing executive, the derail is caught instead by the Multics operating 
system and passed to GTSS. GTSS interprets the derail request and simulates the 
same functions of the GCOS time sharing executive. 


Although some derail functions are not implemented, most functions related 
to the building, editing, and compilation of a user's ¥*SRC current file, with 
subsequent execution of the resulting object code, are provided. 


GTSS SOFTWARE FILES 


The GCOS software used by gtss resides in the gtss fast_library_ file in 
the same directory as gtss. New or replacement GCOS software is added to this 
file with the gcos_tss_build library command. When loading subsystems for 
execution, gtss searches the run-time subroutine libraries gtss_Lstar_ and 
gtss_starL in the same directory. This last file is initially empty and can be 
loaded with site-specific subroutines with the gcos reformat_syslib command. Links 
to these software files may replace the actual files in >unb. 


Programs and commands intended to be loaded from the GCOS libraries CMDLIB 
and LIBRARY may be found in >udd>emdlib>emdlib and >udd>library>library. Files 
in these directories may be restored from a GCOS FILSYS save tape via the gfms 
command. 
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GTSS TERMINAL INTERFACE 


GTSS uses existing Multics terminal interfaces wherever possible. it is 
felt that the GCOS time sharing interface is too restrictive (no echoplex, full 
duplex, canonicalization, type-ahead, etc.), and that users are willing and able 
to learn the Multics interfaces in order to get the Multics functions. 


The following paragraphs describe the steps to be taken by a user wanting 
to use GTSS: 


& User logs into Multics 


The user logs into Multics as a normal Multics user by invoking the 
login (1) command. As such the user is subject to normal Multics 
answering service controls as applied by the system and project 
administrators. 


e GTSS is called 
To enter the GTSS facility, the user types the gcos_tss command. 


When the user types BYE under gcos tss, the user is returned to Multics 
command level. For those individual users who do not plan to use the 
Multics command functions, a simple abbrev/exec_com can be set up to 
invoke GTSS and then automatically logout the user after a BYE. 


* User ID and password input 


There is no additional password required of the user. Under certain 
modes of pathname mapping, the user must give the GCOS time sharing 
USERID. This value is used in the mapping of GCOS pathnames into 
Multics pathnames for applications brought over from native GCOS. 


= Break key (functions normally, as on native GCOS) 


The use of the break key is processed the same as on native GCOS TSS, 
where it causes the currently executing subsystem/command to be reset. 
An option is provided for gcos tss to override this and cause the 
user's process to go to Multics command level. See the description of 
the gcos tss command (described later in this section) for additional 
details. 


a System responds with line feed after each carriage return 


On native GCOS, the user types a CR to indicate the end of the input 
line. GCOS time sharing generally prints an NL and asterisk to indicate 
that it is ready to accept the next input line. On Multics, GTSS uses 
the standard terminal interface for line feed/carriage return processing. 
When GTSS receives another line of input (e.g., build mode), it outputs 
an asterisk without a line feed or carriage return to indicate that it 
is ready for another line of input. 


* GCOS erase and kill characters are provided (Multics set_tty command 
option) 


The GCOS time sharing erase and kill characters are not set by the 
gcos_ tss command. The standard Multics erase and kill characters are 
used to facilitate growth into native Multics. For those users who 
need the GCOS version, the set_tty command may be used to set these 
values. The system does not respond with "DEL" upon receipt of a line 
delete. 


a Terminal input/output is like GCOS (with few exceptions) 


GTSS provides (if possible) additional detail for the user when reporting 
errors. 


aN 
{ 
Nm 


ANOQ5-02 


& Processing input lines with trailing white space 


Normally, Multics discards all trailing white space (blanks and horizontal 
tabs) on input from the terminal. This is incompatible with the input 
of trailing white space on native GCOS. The GTSS user has two options 
available to input lines with trailing white space: 


@ Another character can be used in place of the trailing blank or 


horizontal tab. That character can then be replaced using the 
text editor. 


@ The user can turn off canonicalization of the input lines (native 
GCOS does not provide this function) with the set_tty command. 


Terminal Interface Differences 


The following paragraphs describe the user terminal interface differences 
between the GTSS and GCOS time sharing. 


USER SIGN-ON PROCEDURE 


The sign-on procedure and system greeting message pertaining to Multics 
login (1) are described in the New Users' Introduction to Multics - Part 5 


a ee 


The GCOS time sharing login procedure is described in the Time Sharing 
System Reference Manual, (Order No. DJ31). 


INPUT LINE TRANSMISSION CONVENTION 


The GCOS time sharing convention to indicate completion of a typed input 
line transmission is a carriage return (an ASCII RETURN character -- octal code 
015). 


The GTSS convention to indicate the completion of a typed input line is 
either the ASCII LINE FEED character (octal code 012), or a carriage return. 
The default is newline, but can be changed with the set_tty command to be the 
carriage return (set_tty -modes lfecho). 


EDITING CONVENTION 


Two editing capabilities on the typed line are availiable 
e The ability to delete the last character or characters entered 


* The ability to delete the entire line 


GTSS character-deletion and line-deletion control characters conform to the 
Multics editing convention. The two editing control characters for teleprinters 
(IBM 2741, and DATEL terminals) are: 
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Character control function 
# (number sign) character deletion 


@ (commercial at sign) line deletion 
The GTSS editing rules are: 


T Use of the character-delete control deletes from the current buffer 
line the character preceding the deletion character; use of n consecutive 
deletion characters deletes n preceding characters (including blanks) 
up to the beginning of the line. Although the delete character is a 
printable symbol, it is not retained as part of the line string. 


One character-delete symbol typed immediately after "white space" causes 
the entire white space to be erased. (White space is defined as any 
combination of spaces and horizontal tabs). 
The benefits of the white space concept are: 


a. Reduces the number of keystrokes necessary to remove white space. 


b. Eliminates the need for a user to remember how many spaces or 
horizontal tabs are typed on a line. 


In the following examples an S indicates a space and a T stands 
for horizontal tab: 


TheSSne###next 
or 
TheST#next 
produces "Thenext". As shown in this example, the user may have 
to reinsert an S to space the line to read "The next", if that is 
the desired result. 
2. Use of the line-delete control deletes the entire line. 
For example: 
This is atekt@What is this 
produces: 
What is this 
The Multics user terminal interface provides the user with the ability to 
define the characteristics and modes of a specific terminal associated with 
terminal input/output by using the set_tty command. With this command, the user 
can set various modes to effect certain terminal actions, e.g., specify the 
character-delete and line-delete symbols or “echo" a carriage return and/or line 


feed. For a detailed description of the set_tty command, (see the Commands 
manual). 


ESCAPE CHARACTER CONVENTION 


GTSS conforms to the established character escape convention of Multics, 
represented by the left slant (\). Escape conventions are provided for terminals 


that do not have a full ASCII character set (see the Programmer's Reference | 
manual). 


USER PROGRAM INTERFACE 


For those implemented derail functions, the slave programs experience the 
Same interface as they do on GCOS time sharing. 

* Programs use normal derail to obtain TSS services 
The derail fault is caught by Multics and passed to GTSS. The machine 
conditions are examined to determine the nature and validity of the 
fault. Legitimate derail requests are processed, the IC is adjusted 
to pass over the derail calling arguments, and control is returned to 
the user. 

& Privileged code not accommodated 


The effort to accommodate privileged code is not justified at this 
time. 


@ Existing user subsystem, linked object files usable as is 


Users can directly execute programs and access files brought over from 
GCOS time sharing (i.e., recompilation and linking not required). 
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SECTION 7 


OVERVIEW OF DERAIL PROCESSING 


This section describes the differences in derail processing between native 
GCOS and GTSS. Complete documentation of the GCOS derails can be found in the 
Time Sharing System Reference Manual, (Order No. DJ31). 


Intentional faults, called derails (DRLs), are mechanisms used by GTSS to 
request service functions instead of the MME functions used in the batch processing 
environment. 


Every attempt is made by GTSS to process DRLs in the same manner as the 
native GCOS TSS. Since the Level 68 hardware is a superset of the Level 66 
hardware, the hardware mechanisms for processing DRLs are identical. Some features 
of native GCOS TSS DRLs are not supported by GTSS DRLs; these differences are 
noted below. 

ABORT - is supported 

ABTJOB - is supported 

ADDMEM - is supported 

ATTRI - is not supported 


CALLSS - is supported as qualified 


the Multics virtual storage stacking facility is utilized when the 
current (calling) subsystem must be "swapped out." Note that there is 
no equivalent of the native GCOS swap file; four stack levels are used 
instead. 

CGROUT - is not supported 

CONSOL - is not supported 

CORFIL - is supported 

DEFIL - is supported 

DIO - is supported 

DRLDSC - is not supported 

DRLIMT - is supported as qualified 
this implementation does not update the processor time limit for the 
subsystem in ".limit™ of the user status table (UST). 

DRLSAV - is supported 

FILACT - is supported 


FILSP - is supported 
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GROW - is supported 

GWAKE - is supported 
time delay is in seconds 

JOUT - is not supported 

JSTS - is supported 

KIN - is supported 

KOTNOW - is supported as qualified 
DRL KOTNOW and DRL KOUT are condensed into one derail module. Note 
that the derail processor utilizes the tally words which are modified 
on return to the subsystem. Therefore, they must be refreshed prior 
to each execution. 


KOUT - is supported as qualified 
see KOTNOW 


KOUTN - is supported as qualified 
the new line code (octal 12) transmitted by the Multics input manager 
is replaced by a carriage return code (octal 15). 

MORLNK ~ is supported 

NEWUSER ~ is not supported 


OBJTIM - is supported as qualified 
memory limit is initialized at 261120. 


PART - is supported 
PASAFT ~- is supported 
PASDES - is supported 
PASFLR - is supported 
PASUST - is supported 
PDIO ~ is supported 
PRGDES - is supported 
PSEUDO - is supported 
RELMEM - is supported 
RESTOR - is supported 
RETFIL - is supported 
RETURN - is supported 
REW - is supported 
RSTSWH - is supported 
SETLNO - is supported 
SETSWH - is supported 
SNUMB - is not supported 
SPAWN - is not supported 


STATUS - is not supported 
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STOPPT 
STPSYS 
SWITCH 
SYSRET 


TAPEIN 


LUCID mode (8-bit input) is not supported 


TASK - 
TERM - 
TERMTP 
TIME - 
T.CFIO 
T.CMOV 
T.CONN 
T.CRYe 


TeRRR = 


T.MAIL 
T.MODR 
T.MODS 
Ta PAGE 
T.RSCC 
T. STAT 
T. SYOT 


USERID 


12/385 


- is supported 
- is not supported 
- is supported 
- is supported 


- is supported as qualified 


is not supported 
is supported 

- is supported 

is supported 

- is supported 

- is supported 

- is not supported 

- is not supported 
is supported 

~ is not supported 

- is supported 

- is supported 

- is not supported 

- is not supported 

- is not supported 

- is not supported 

- is not supported 


- is not supported 


- is not supported 
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SECTION 8 


GTSS COMMAND LANGUAGE 


GTSS consists of a time sharing executive, a number of independent processing 
subsystems which operate under the executive, and a common command language. 
Complete documentation for the TSS system can be found in the Time Sharing 
System Reference Manual. The following list identifies some of the major TSS 
subsystems. 


ABACUS 
a desk calculator facility featuring complex algebraic capabilities 
such as functions, summation operations, and remembered variables. 


BASIC 
an algebraic-language compiler/executor designed for the user with 
numerical calculations involving relatively small quantities of data. 


Text EDITOR 
a facility for building,. maintaining, and reformatting (RUNOFF) text 
files. 


TSS ALGOL 
an ALGOL subsystem that provides the TSS user with the capabilities of 
the ALGOL language. 


TSS JOVIAL 
a JOVIAL subsystem that provides the TSS user with the capabilities of 
the JOBIAL Language processor. 


TSS FORT 
a time-sharing-based FORTRAN subsystem. 


The following subsystems and subroutines provide service and utility functions 
for GTSS: 


ACCESS 
is a file system that allows the user to create, delete, and modify 
file system catalogs, subcatalogs, and named files. Oniy the file 
Space, not the content, is affected by ACCESS. 


Command Loader 
is a default subsystem which is invoked whenever an unrecognized command 
is given, either at svstem-selection level or in line-numbered mode. 
Input is assumed to be the catalog/file description of an H* file to 
be loaded and executed, or a series of responses for a command file 
application. 


CONVER 
is a media-conversion tool, which provides the user with the ability 
to transliterate files from one media code to another. 


F DUMP 
is a remote terminal, word-oriented file inspection and maintenance 
facility for files, regardless of their format. 
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HELP 


LODS 


LODT 


LODX 


SABT 


permits a terminal user to obtain an explanation of a system error 
message. 


provides a debugging environment for a specified TSS subsystem by loading 
the Debug Trace Package with the subsystem. 


similar to LODS, except the debugging environment is provided for a 
user program resident on an H*® file. 


allows the user to load and execute a program resident on ah H* file. 


retrieves specific locations of the ABRT file for printing (on either 
a user terminal or optionally on the central site printer). The file 
named ABRT must be created by the user and entered into the Available 
File Table(AFT). 


The primary functions of the time sharing command language are: 


Initiation of processing within a subsystem (e.g., LIST and RUN commands). 


Storage, retrieval, and purge of permanent files (e.g., SAVE and OLD 
commands), 


Request for operations on temporary time sharing files (e.g., NEW and 
RESEQUENCE commands). 


Request for pertinent operations information (e.g., HELP and STATUS 


commands). 


Direction of flow of control within the subsystem (e.g., DONE and BYE 
commands). 
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APPENDIX A 


MULTICS GCOS DAEMON 


The GCOS daemon is a facility designed to aid in the simulation of a GCOS 
environment on Multics. The daemon allows standard GCOS jobs to be submitted 
from either punched cards or IMCV magnetic tapes in GCOS standard system format. 


DAEMON COMPOSITION 


The GCOS daemon comprises the following routines and procedures: 


& Main routine 
Initialization routine 


Two procedures to prepare for reading: one for punched cards and one 
for IMCV magnetic tapes 


Generalized read routine 
Job queuing routine 


Procedure for converting GCOS time to Multics time 


USER INTERFACE 


Users submit GCOS job card decks and IMCV tapes to Multics operations personnel 
who activate the GCOS daemon to process the input jobs. 


In order to use the GCOS daemon services, users must first be registered on 
Multics as a user and also be registered to use the GCOS daemon. The GCOS 
administrator for the site can do this. Specifically, an entry must be made in 
the gcos_user_table_ that defines the account_id to be specified on the $ IDENT 
ecard and the Multics user_id for whom the job is to be run. (Refer to Appendix B 
for more details.) 
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DIRECTORY STRUCTURE 


daemon dir dir 


FLOW OF INPUT AND OUTPUT 


Anonymous 


The simulator job stream is read into a segment named snumb.gcos in the 
directory input dir. The snumb is taken from the $ SNUMB control card. When a 
$ IDENT card is encountered in the input stream, the account number field is 
used to do a table lookup of a person.project for which the daemon requests an 
absentee job be submitted. 


NOTE: The term "segment" refers to either a segment or a multisegment 
file, as needed. A segment is a collection of instructions and/or 
data that is associated with a particular segment name (i.e., a 
file). 


The daemon creates an absentee file in the directory gdd>Project>Person 
with the file name snumb.absin, where the snumb is taken from the $ SNUMB card. 
When the absentee job is executed, two output files are created: snumb.absout 
from the absentee job and output files from the GCOS job. Both of these output 
files are created in the user directories. The snumb.absout file is printed via 
the dprint option. The job output files are printed via the dprint option or 
punched on cards via the dpunch option, as specified by the GCOS job, for snumb.gcos. 


JOB PRIORITIES 


If an urgency level field is encountered on the $ SNUMB card, it is used to 
compute the priority level at which the absentee job and generation of results 
are queued. 


# If the urgency number is 0-21, the third priority absentee queues are 
used. 
* If the urgency number is 22-42, the second priority absentee queues 


are used. 


* If the urgency number is 43-63, the first priority absentee queues are 
used. 
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The default is to use the third priority absentee queue. Usage of the 
priority absentee queues can be restricted by setting appropriate access on 
them. To prevent GCOS users from dominating absentee or printing facilities, 
the operator also can set the highest priority queue that all GCOS jobs can use. 


OPERATOR INTERFACE 


The daemon is activated at the command level by the operator, who enters 
the. daemon. name. GCOS. SysDaemon..via..the. daemon console... The.daemon then types 
the message ENTER REQUEST on the console. 


Procedures differ slightly depending upon whether input is via punched cards 
or an IMCV magnetic tape. 


* If input is via punched cards, the operator enters the attach command 
to attach a card reader, and enters the read command to issue a read 
request to the card reader. 


The daemon then goes blocked waiting for placement of a card deck in 
the card reader. When a deck is read, the daemon processes it and 
again types ENTER REQUEST. 


When all cards have been read in, or if the card reader is needed for 
another use, the operator enters the command "detach" to detach the 
device. 

The operator then enters "logout" when processing is completed. 

* If input is via an IMCV magnetic tape, the operator enters the 
"imev reel_id" command for nine-track tape, or “imev7 reel _ id" for 
seven-track tape. This command is followed by an argument or arguments 
specifying the jobs on the tape to be executed. 

Tne daemon attaches an appropriate tape drive, reads the tape, 
automatically detaches the tape drive, and processes the appropriate 
jobs. 


The operator logs out the daemon by entering "logout" via the daemon 
console. 


NOTE: Jobs on magnetic tape can be read in while the card reader is 
not attached. 


DAEMON COMMANDS 
The daemon executes any of the following requests when at command level: 


invokes a self-identify request. 


2 
prints a list of daemon requests (same as the help request). 

abort 
terminates the current daemon job (usually as a result of a quit 
signal being issued). The effect is analogous to the release command 
at Multics command level in that the daemon is returned to request 
level after cleaning up from the job in progress. 

admin 


enters admin mode (requires password). (The admin mode is a means 
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attach 


detach 


of entering the standard MulticS command mode under the authority of 
the daemon.) 


attaches the card reader. 


detaches the card reader. 


imev reel _id-option 
imev?7 reel id-option 


help 


logout 


read 


re_init 


request for reading in a job or jobs from an IMCV magnetic tape: 
Where “imev reel id" indicates a nine-track tape is being used, and 
“imev? reel_id" ‘indicates a seven-track tape is being used. The 
system replies with mounting instructions, or with a message indicating 
the tape unit is not available. One of the following options must 
be included as an argument (option): 


-all 
all jobs on the IMCV magnetic tape are accepted. 


-deletebsssss...Sssss 
all jobs except those specified are read in from the tape. 
From one to five snumbs are allowed. After the tape is read, 
it is detached. Those jobs read from tape are queued as absentee 
jobs. 


-startbsssss 
beginning with the indicated snumb, all jobs through end of 
file are read in. 

-startBsssss...Sssss 
beginning with the first snumb, all jobs up to but not including 
the second snumb are read in. 

-takebbsssss...Sssss 
only those snumbs specified for execution are read in. From 
one to five snumbs are allowed. 

NOTE: The hyphen preceding these command options is optional. Also, 


each #& represents one blank space and is not a character 
entry. 


prints a list of daemon requests (same as the "?" request). 
logs out the daemon. 
issues a read request to the card reader. 


reinitializes the daemon. 


set_maximum_queue_level 
smq_level 


start 


sets the maximum priority at which jobs can be queued. 


resumes processing from the quit signal. 


RECORD QUOTA OVERFLOWS 


read 


If a record quota overflow occurs while a job is being read in, that portion 
in is deleted and an appropriate message is printed on the daemon console. 


All ANO5-02 


Record quota overflows occurring while in the absentee process cause the absentee 
process to signal the daemon to print amessageon the console so that the operator can 
take some appropriate action (e.g., suspend absentee processes). The GCOS routines 
are responsible for "cleaning up" the geos pool directory. 


rere er ee ree eee 


The GCOS daemon uses the account number field from the $ IDENT control card image 
of a GCOS job to determine the Multics person and project identifications for the job 
to be run. This correspondence between the GCOS account number and the Multics 
person-project identifications is maintained in a table (geos_user_table_) in the 
GCOS daemon's home directory. 


A number of commands (described in the following paragraphs) are provided to 
maintain this table. These commands are: 

gcos_userg$add 

gcos_user$delete 


gcos_user$init table 
gceos_user$print 


Creating GCOS User Table 


The table is created by using the Multics create command: 


ewd >ddd>GCOS 
er geos_user_table_ 


Initializing the User Table 

The following command initializes all header data in the geos_user_table_ 
segment: 

geos_user$init table 

NOTE: The geos_user_table_ bit count must be zero before initialization is 


allowed. If an existing table is to be re-initialized, the bit count must 
be set to zero. 


Adding Users to Table 


The following command adds a user to the table: 
geos_user$add 


The command prompts the caller to enter needed data. (The entries below, preceded by 
the exclamation mark (!), indicate user response.) 


GCOS account ID? 

! (GCOS account identification) 
Multics Person Name? 

! (Multies person identification) 
Multices Project ID? 

! (Multiecs project identification) 
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Examining Table Contents 
The following command allows the caller to examine the contents of the GCOS user 
table: 


gecos_user$print {-control_ args} 


where control _ args are: 


-geos_account_id ID1 {ID2...IDn}, -gaid ID1 {ID2...1Dn} 
each IDn is another argument specifying a GCOS account number. The command 
prints the corresponding Multics person-project identifications. 


-header, -hdr 
causes the command to print status information about the table. There are 
no additional arguments. 

NOTE: The -gcos account_id and -header control arguments may be mixed on a 


command line, and are processed in the order in wnich they are specified. 
Multiple occurrences of either, or both control arguments are permitted. 


Deleting From Table 


The following command allows the caller to delete entries from the table: 
geos_user$delete geos _account_id_ {... gcos_account_idn} 


where gcos_account_idi is the first account number in a string to be deleted and 
geos_ account _idn is the last account number in a string to be deleted. 


INSTALLING THE GCOS DAEMON 


In addition to having the GCOS SysDaemon procedures installed, the SysDaemon 
must be registered anda number of directories and segments must be created to support 
operation of the SysDaemon. Creation of the segments can be delegated to a GCOS 
project administrator. 


Registering the SysDaemon 


Ty The daemon should be registered in the SysDaemon project under the name 
GCOS. A password and normal daemon attributes should be included. The 
project master file entry must include: 

homedir: >ddd>GCOS; 
initproc: >pathname>gcos daemon; 


ce A GCOS project must be created and the user "Anonymous" registered with a 
password and normal attributes. The project master file entry must 


include: 
homedir: >ddd>GCOS>Anonymous; 
initproe: process overseer ; 
ring: 5,53 
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36 A GCOS directory must be created under the daemon_directory directory 

(ddd) and include the input_dir, pool_dir, and Anonymous subdirectories 
(see the directory structure diagram in Appendix A). 
The ACLs for the subdirectories must include: 

sma GCOS. SysDaemon.# 

sma Anonymous.GCOS.* 

sma Administrator. Project.* 

NOTE: *.SysDaemon.* includes GCOS.*SysDaemon.*. 


The project administrator should have at least s (status) access on 
>ddd>GCos. 


The initial ACLs for the subdirectories must include: 
rw Anonymous.GCOS, * 
and should include: 


rw Administrator. Project.* 


CREATING THE GCOS SYSDAEMON USER DIRECTORY STRUCTURE 


ce te mn eee 


The directory geos directory directory (gdd) must be created to contain the user 
directories and segments referenced by the SysDaemon. The structure of this 
directory is analogous to that of the user_directory directory (udd). Each 
project.person using the SysDaemon must have a directory under >gdd (see the Multics 
storage system hierarchy in Figure 1-1). 


The ACLs for each person directory must include: 


sma GCOS. SysDaemon.* 
sma Anonymous.GCOS. * 
sma Person.Project.* 
sma Administrator. Project.* 


The initial ACLs must include: 
rw Anonymous.GCOS.* 

and should include: 
rw Person. Project.*® 


rw Administrator.Project.* 


The administrator needs sma access in the superior directories to create the 
project and person directories. Note that the project administrator also needs 
access rignts to tne geos_user_table_ to maintain the table. 
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APPENDIX B 


INSTALLATION AND MAINTENANCE OF GCOS SOFTWARE- 


COMMANDS 


The following commands are used to create and update the software and subroutine 
libraries required by the gcos and geos_tss commands. The input files for these 
maintainance commands may be either files copied from the GCOS total system tape or 
files produced by these commands, or both. These commands allowa site to install PSP 
software or updated releases of GCOS, 
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geos_ build library geos_build_library 


Name: geos build library, gebl 


This command builds a GCOS simulator software library from a native GCOS 
system-loadable file and optionally appends a second software file. A catalog (or 
load table) is built from information on the input file and the optional append file, 
and occupies the first 1900 words of the output file. This process is analogous to 
building the "GECALL TABLE" by GCOS, at startup, and exists for the same reason (i.e., 
to facilitate loading of the individual modules). 


Usage 


gebl input _path output _path {-control args} 


where: 


Tis input path 
~ is the pathname of the input file. This file mayor may not already havea 
catalog. This file may have been created by this procedure, in which case 
it has a catalog, or by the gcos extract module or gcos pull _ tape, in 
which case it would not have a catalog. 


os output path 
“is the pathname of the file into which the modules in the input file (plus 
those in the optional append file) are to be copied, preceded by a 
catalog. If this file already exists, it is overwritten, with no 
warning 
33 control args 


can be selected from the following: 


-append append path 
append path is the pathname of a file whose contents are to be appended to 
those of the input file (i.e., copied to the end of the output file) before 
the new catalog is built. 


-brief, bf 
suppresses printing of the catalog (load name and offset) of output_path. 


Notes 


The catalog occupies the first 1900 words of the output file, and has space for 
499 entries. 


Existing modules are not replaced by the appending function. The only way to 
replace an existing module with a different version of itself is to extract from the 
existing library, into anew file, all the modules except the one(s) to be replaced, 
extract the new versions of those modules into the new file (they are appended to those 
previously extracted into the file), and then build a catalog for the new file. 


This command cannot be used to manipulate a random system-loadable file since the 


catalog created differs from the format of the catalog produced by SYSEDIT (commonly 
used for ** files). 
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geos build_library . geos build library 


This command is not used to convert the GCOS subroutine libraries (the 
SOFTW-SYSLIB files) to a form usable by the GCOS simulator. To do this, the 


geos reformat_syslibd command is used. 


Example 


Assume the software_1.gcos and software 2.gcos files have just been read froma 
GCOS Total System Tape with the geos pull _tapefile command. A single GCOS simulator 
library named geos system_software is to be built which contains the software on 
these two files. The command to do this is: 


gebl software _1.gcos geos system _software_ -append software 2.gcos 


The gcos_ system_software_ file can now be used by the gcos or gtss command and the 
software _1.gcos, and software 2.gcos files may be deleted. 
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gcos extract module geos_ extract _module 


a a an re er re a RS 


Name: gcos _extract_module, gcem 


This command extracts one or more modules from a (tape format) GCOS 
system-loadable file, or a simulator-format software library, placing them in an 
output file. The names of the modules to be extracted are given in acontrol file. 


Usage 
gcem control path input _path output _path {-control arg} 


where: 


Ts control path 
is the pathname of a segment containing the names of the modules to be 
extracted (in lowercase ASCII), each on a separate line. This segment 
can be created by the geos library summary command, using the -brief 
control argument and preceding it by the file output command, and then 
editing the resulting segment to remove the names of unwanted modules; or 
the segment can be created directly by any of the Multics editors. 


es input_path 
is the pathname of a file containing GCOSmodules. It can bea filecopi 
from a GCOS total system tape with gcos pull _tapefile, or it may be 
simulator-format library produced by gcos build library. 


ed 
a 


ce output path 
is the pathname of the output file into which the extracted modules are to 
be written. If the file already exists, it is appended to, enabling the 
construction of a single library from several smaller ones. 


4, control arg 
can be -brief which inhibits printing the name of each module copied. 


Notes 


The names of each module copied are printed on user_output, unless the -brief 
control argument is given. The names of any requested modules that are not found in 
the input file are printed on error _output. 


This command cannot be used to manipulate a random system-loadable file (GCOS 
format **, Q® or H*® file). 
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gceos_ library summary geos_ library summary 


nn ee es erates 


Name: gceos library summary, gels 


This command prints a summary of the contents of a GCOS tape-format 
system-loadable file or a simulator-format software library. 


Usage 


gels path {-control_args} 


where: 
Hy path 
is the pathname of either a GCOS format system-loadable file or a 
simulator-format software library file. 
ee control_args 
can be selected from the following: 
-brief, -bf 
prints only the names of the modules, omitting any preface or catalog 
information. 
-gcos, -ge 
identifies the input file as a GCOS ** file. 
-preface 
prints the preface record information found at the beginning of each 
module. 
Notes 


If path is a GCOS format file as copied from a Total System Tape, then gels lists 
the modules and the preface information. 


If path is a GCOS simulator-format library, then gels lists the module names and 
the catalog offset. 


If path is a native GCOS ** file and -gcos is specified, then the modules on the 
file are listed. 
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geos pull tapefile gcos pull tapefile 


Name: gcos pull _tapefile, gept 


This command copies files from a GCOS tape into the Multics storage system. 
Sinee it was designed to read files from a total system tape, from which the geos 
simulator libraries are built, it accepts records longer than 320 words. It reads the 
header label preceding each file, prints the name and file sequence number, and asks 
the user if the file is to be copied. If the answer is yes, it asks for a pathname, and 
copies the file into it. Then it continues with the next file. This process is 
terminated either by areplyof "quit" to the copy question, or an end-of-reel label or 
partial label on the tape. 


Usage 


gcpt {reel number} {-control_ args} 


where: 

1. reel number 
is the number of the tape reel to be read. It need not match any field in 
the tape labels. (See -attached control argument.) 

fale control args 


can be selected from the following, and can be in any order: 


NOTE: The following list identifies all control arguments grouped by 
funetion. 


ATTACHING TAPE 
~attached 
-block 
-density 
-detach 
-gsr 
~retain 


PROGRAM CONTROL 
-brief 
-long 
-~long brief 
-skip 


-attached, -att 
may be given in place of reel_number to indicate that the tape has been 
retained from a previous use of this command and is already mounted. (See 
-retain control argument) 


-block N 
N specifies the tape buffer size (any value up to 4096) needed to read a 
GCOS total system tape. This argument is not required inorder toreada 
total system tape, but is needed for tapes with records larger than 3842 
words. (Default is 3842) 


-brief, -bf 


specifies that certain warning and informative messages NOT be 
displayed. 
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geos pull _tapefile geos pull tapefile 


-density N, -den N 
N specifies tape density. (Default is 1600) 


-detach, -det 
specifies detaching and dismounting of the tape before any attempt is 
made to attach the currently specified tape. If this is the only argument 
given, the tape is detached and no other processing takes place, 


-gsr 
specifies standard size records (320 words or less) to be copied into the 
Multices storage system in a format readable by other Multics tools that 
manipulate GCOS files. Records shorter than 320 words are padded out to 
320 words, allowing a read of 320 words to obtain exactly one record. 
This argument should not be used when reading a total system tape. 


-long, -lg 
specifies that hardware status, Labels, and length and first word ofall 
data records be displayed. 


~long brief, -1lb 
specifies that hardware status and labels be displayed, but length and 
first word of data records NOT be displayed. 


“retain, -ret 
specifies that the tape remain mounted when processing by this command is 
completed. This saves work for the Multics operator if several attempts 
to read the tape are to be made. 


-skip N 
N specifies the files to be skipped over before the user is asked if files 
are to be copied. (Questioning starts with N+ist file.) 


Examples 


Assume a 1600-bpi GCOS Total System Tape, reel number U812, contains the 
following software files: 


SOF TW-S YSLIB 
GCOS~PART 1 
GCOS~PART2 
TSS-SUB-S YS 
SOF TW~PART 1 
SOF TW-PART2 


The geos_ pull _tapefile command is used to copy the softw-syslib, softw-part1, and 
softw-part2 tape files into Multics segments. The path names used for the input copy 
files may be any valid Multiecs name. 


! gept usi2 
Tape u812,den=1600,block=3842 will be mounted with no write ring. 
Tape u812,den=1600,block=3842 mounted on drive tapa_03 with no write ring. 
File 1. is "softw-syslib" 


! Copy? yes 
! Pathname of file to copy to: softw_syslib.gcos 
998 tape records read, 313 Multics records (pages) written 


End of File 
File 2. is "gcos-parti" 
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gcos pull tapefile geos pull _tapefile 


! Copy? no 
End of File 
File 3. is "geos-parte" 


§! Copy? no 
End of File 
File 4. is “tss-sub-sys" 


! Copy? no 
End of File 
File 5. is "softw-parti" 


! Copy? yes 


! Pathname of file to copy to: software_1.gcos 
410 tape records read, 442 Multics records (pages) written 
End of File 
File 6. is “softw-parte2" 


! Copy? yes 


! Pathname of file to copy to: software 2.gcos 
896 tape records read, 1382 Multies records (pages) written 
End of File 
Partial label (end of tape). 


The following example shows how a single file, tss-sub-sys, may be copied. 


! gept u812 -skip 3 -bf 
Tape u812,den=1600,block=3842 will be mounted with no write ring. 
Tape u812,den=1600,block=3842 mounted on drive tapa_03 with no write ring. 
End of File 
End of File 
End of File 
File 4. is "tss-sub-sys" 


! Copy? yes 

! Pathname of file to copy to: gcos_tss_ software update 8 
188 tape records read, 316 Multics records (pages) written 
End of File 
File 5. is "softw-part1" 


! Copy? quit 
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gceos reformat _syslib geos reformat _syslib 


er re ee eer 
~ —— 


Name: gcos reformat syslib, gers 


This command reformats the softw-syslib file (the library used by GELOAD) from 
the total system tape, so that it can be read by the simulator. 


Usage 


gers input_path foutput_path} {record length} 


wnere: 


ss input path 
is the pathname of the file pulled from a GCOS total systems tape. 
Typically, this is the file for "softw-syslib." 


ae output path 
is the pathname for the reformatted data. 


If output _path is not given, the modifications are made to the input file. 
Since a temporary file is not used, quitting and releasing while updating 
the input file leaves the file in an inconsistent state, from which 
recovery is almost impossible. 


3 record length 
is tne number of words from each input record to be written to the output 
file after the first data word of each input record is discarded. 


If record length is not given, the default is 321. Record length is 
distinguished from output_path in that it must be numeric. It may 
precede or follow output path, and output_path need not be given when 
record length is given. 


Notes 


As read from the total system tape, the file contains 321-word blocks. The first 
is a block control word (BCW), and the next 320 make up a block that GELOAD interprets 
itself. The BCW of each block is discarded, and the remaining 320-word blocks are 
packed together. If read from a7-track tape, the word count is rounded up to the next 
even number (322), so a word at the end must also be discarded. Thenumber of words to 
be read is therefore an optional argument, with the default being 321. The first word 
is discarded, and the next 320 words are always retained. 


The first word (the BCW) is checked for sequential block serial numbers (BSN), 
and block lengths of 320 words or fewer, to verify that the correct record length was 
used for reading, and that the words being discarded are really BCWs. 
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geos tss_ build library geos_ tss_ build library 


Name: gcos_tss_ build library, gtbl 


This command builds or updates the GCOS software library, Stss fast _library_ 
used by gcos_tss, and updates the program descriptors required to aecess the added 
software. 


Usage 
gtbl input_libs {-control_args} 


wnere: 


1. input_libs 
are the pathnames of one or more GCOS software libraries. The input 
libraries are either in native GCOS format (as copied from a GCOS total 
system tape) or in GCOS environment simulator format (as output from 
geos_ build library). 


2. control args 
can be one or more of the following: 


-brief, -bf 
Suppresses printing of information concerning updated modules and 
program descriptors and the catalog, even if requested by the 
-print_catalog control argument. 


-module file path, -mf path 
path specifies the segment containing a list of modules to be moved from 
the input libraries to the output library. These names are added to those 
specified by the -module control argument. 


-modules STR1 {...STRn}, -mods STR1 {...STRn} 
STRi specifies the name of the module to be moved from an input library to 
the output library. These names are added to those specified by the 
-module file control argument. 


-output_ library path, -olb path 
specifies the path of the gtss fast library output library. If the 
library already exists, it is appended to. 


-print catalog, -prceat 
prints the catalog (modules and offsets) of an input library if the 
library is in simulator format. 

-program descriptors path, -prgdes path 


path specifies the gtss program descriptors (a copy of 
gtss_ prgdes alm_.incl.alm) to be updated. 


Notes 


If no output library path is specified, then only a list of the modules found on 
the input libraries is printed. 
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geos_ tss_ build library geos tss build library 


To use the added modules in gtss, the -prgdes control argument must be used. Then 
gtss prgdes ext_.alm must be reassembled with the gtss_prgdes_alm_.incl.alm | 
specified by -prgades. Following this, gtss must be rebound with the new 
gtss prgdes ext_, and the updated output library must be copied to gtss fast_library_ 
in the directory containing gtss (or a link established). 


This is the only procedure required to add PSPor user software to the gcos tss 
library for which there are program descriptors. 


If the -modules and -module_ file control arguments are not specified, then all 
modules found on the input libraries are copied to the output library. The only 
exception is when the -prgdes control argument is specified. In this case, only 
modules on the input libraries, which are actually needed by the program descriptor 
file, are copied. 


Example 


Assume that the segment pcef_softw exists, having been copied from a GCOS tape 
with the geos pull tapefile command and that gtss_prgdes_ alm_.incl.alm has been 
copied to the working directory. The command to add pef_softw to the known gtss 
subsystems is: 


gtbi pef_softw -olb >unb>gtss fast_library_ -prgdes gtss_prgdes_alm_.incl.alm 
When finished, the command prints: 

Updated program descriptors will be labeled "11/30/83 1113.4", 

Added module ".PCPCF" from >udd>ges>4 js3>pef_softw 

Added program descriptor 106 for ".PCPCF". 

This shows tnat the single module ".PCPCF" from the input library pef_softw has 
been appended to the output library gtss fast library _. Program descriptor 106 in 
gtss prgdes alm_.incl.alm has been updated with the load information for the module 
and the date/time it was added. 


When the gtss modules referencing the prgdes include file are recompiled and gtss 
is rebound, the new software in gtss fast_library is accessible. 
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STEPS TO BUILD GCOS SOFTWARE AND LIBRARY FILES 


cee ee ee ne ees 0 eee 0 eeeee 


The following steps describe how to use the maintenance commands (above) to build 
or update the three kinds of GCOS software files required by gcos and gtss. The GCOS 
software files shipped with geos and gtss include all the most recent bundled GCOS 
software available prior to the Multics release. These files may be used as shipped, 
unless a site needs to install a subsequent GCOS release or any unbundled GCOS 
software. 


a 


Follow these steps to build the gcos system_software and gcos second software_ 
files and any other GCOS load file from a GCOS system tape. 


1. Use the gcos_ pull _tapefile command to pull each desired file off of the GCOS 
Total System Tape (TST) and into a separate segment (or MSF). 


2. Use the geos_ build library command to convert these files into the 
geos system_software_ file (for bundled software) and 
geos second software (for unbundled software). The files read from a 
GCOS tape can be concatenated into a single software file, but a separate 
run of geos build library is required for each file added. The file 
ereated by gcos build library is limited to 500 load modules. 


3. Onee the gcos system_software and gcos_second_software_ files are 
created, their input files (the ones read by gcos_ pull _tapefile) can be 
deleted. 

4, Use the geos library summary command to produce a list of the load modules 


on the gcos_system_software and gcos_second_software_ files. 


ae Wnen copied into the >unb directory (see Note), geos_system_software_ and 
geos_ second software files are immediately available to the gcos command. 
The geos_ second software_ file is searched only when the -userlib control 
arg is used. 


ED TE RE EE Eee neem 


Follow these steps to build subroutine library files from the SOFTW-SYSLIB tape 
file. 


Li Use geos pull _tapefile to read the SOFTW-SYSLIB file off the TST or 
unbundled software tape. (This file has the same name regardless of its 
content. Some sites may only get a single, customized version.) 


2. Use the geos reformat_syslib command to restructure the syslib file into 
one usable by the simulator. Name it gcos library subroutines _ (or 
geos_ altlib_subroutines_ if it only contains unbundled software.) 


3. Add the name gceos Lstar_ to gcos library subroutines and the name 
geos starL_ to geos_altlib_ subroutines . 


4, When moved to >unb (see Note), the gcos library subroutines file is 


available to the gcos command. The altlib file is accessed via the "$ 
LIBRARY ¥*L..." control card with Multics path given. 
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To access geos library subroutines from gtss, make the primary name 
gtss_ Lstar_ (note the uppercase L). Now run the ec in >unb to add the 
necessary gtss file attributes: 

ec gtss file attributes gtss Lstar_ r 


The r argument is required. 


To access geos altlib subroutines from gtss, make the primary name 
gtss_starL_. Run the ec as in step 5. 


ec gtss file attributes gtss starL_ r 


Both gtss_ Lstar_ and gtss_starL_ are immediately available to gtss when 
moved to >unb and these add names are the PRIMARY names. 


Building the GTSS Command File 


Follo 
tape file. 


Ve 


Note: 
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w these steps to build the gtss_fast library _ file from the TSS-SUB-SYS 


Use the geos_ pull tapefile command to read the appropriate TSS files from 
the TST tape. These include SOFTW-PART1, SOFTW-PART2, and TSS-SUB-SYS 
(some sites may have others). 


OPTIONAL STEP FOR SITES WITH UNUSUAL TSS INSTALLATIONS. 


a. Use gcos card utility to read GCOS GMAP source of module TSSA from GC2 
source tape. Write to Multics ascii text segment "tssa.ascii". 


b. Compare tssa.ascii to gtss_prgdes_alm_.inel.alm and make the 
required load module NAME changes in the include file. Youmay have to 


eonvert tssa.ascii to ALM. 


Use the gcos tss_ build library command to convert the GCOS files read from 
the TST tape in Step linto the gtss fast library file. This command also 
updates the gtss prgdes_ alm_.incl.alm include file. 


Reassemble gtss prgdes_ext_.alm with the updated 
gtss_prgdes alm_.incl.alm. (If the NUMBER of program descriptors was 
changed in step 2, then make that change in gtss_primitives_.inel.pli and 
gtss_prgdes_.inel.pl1 and recompile ALL gtss pli modules.) 


Rebind gtss. 


The newgtss fast library is available to gtss when it and the newly bound 
gtss are moved into >unb (see Note). 


Steps 1 through 6 can be repeated to add new TSS modules to 
gtss_fast_library . 


A user working directory can be substituted for >unb for all of these 
procedures for test and verification, but this directory must contain 
or have links to all of geos, gtss, and the related geos software 
files. 
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APPENDIX C 


GCOS ENVIRONMENT SIMULATOR AND NATIVE GCOS DIFFERENCES 


Detailed differences in GCOS environment simulation and native GCOS functions 
or responses are noted in the sections of this document that describe the specific 
functions, especially in those sections describing MMEs and control cards. This 
is a brief discussion regarding some of the basic reasons these differences 
arise. 


The GCOS environment simulator is not an operating system. It is a Multics 
subsystem whose purpose is to run GCOS jobs with native GCOS software (i.e., 
compilers and utilities), thereby eliminating any differences in job results. 
To this end, the environment simulates the GCOS functions of intrajob scheduling 
of activities and the calling of required software and service functions. 


All other operating system functions (i.e., file management, resource 
allocation, dispatching, input/output, ete.) are performed by the Multics operating 
system. Therefore, the GCOS environment does not simulate these GCOS operating 
system functions. 


Further, the GCOS environment need not and does not simulate in detail the 
intrajob scheduling function of GCOS. (However, since both are time sequential, 
they have the same general form.) In part, this is because of the simplifying 
restriction of having one GCOS job per Multic 
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The environment simulates GCOS by: 


Reading the job stream 


Interpreting the job control cards to obtain system resources from the 
Multics operating system and to control job activity execution 


Initiating, monitoring, and terminating job activities 
Interpreting slave job requests for GCOS operating system services and 


making equivalent requests to the Multics operating system 


The environment must work through the Multics input/output (and peripheral 
allocation) system and the Multics file structure. 


Differences arise when an equivalent function cannot be performed under 
Multics, or when the equivalent function is not meaningfully expressed in GCOS 
terms; for example, GCOS file code assignment via the system configuration table 
number, or file sizes expressed in links or llinks. 


Differences also arise when a GCOS function is simulated functionally, but 
not in detail. 
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Finally, usage statistics - where they are available - come from the Multics 
system accounting procedures and may not correspond to GCOS usage statistics. 


If these basic structural differences are kept in mind, it may help in 
understanding those detailed differences that are noted elsewhere in this document. 


Another approach to describing the GCOS environment is to consider it, in 
GCOS terms, as a special GCOS system operating from disk to disk with offline 
input and output (with the exception of data tapes). 


From this viewpoint, the GCOS daemon provides offline local batch input 
from punched cards or IMCV magnetic tapes to a disk buffer file. This is equivalent 
to input entered via GCOS remote system input (.MRGIN). The GCOS daemon also 
assumes the system scheduler function by queuing the job in the Multics absentee 
job facility. 


= 


Alternatively, jobs can be entered offline via a Multics interactive terminal 
in a manner that is equivalent to GCOS time sharing. 


The GCOS environment reads the job stream from the disk file through the 
equivalent of the .MGENB module (Mass Store Device Input) of system input (.MGEIN). 
Output is roughly equivalent to SYSOUT that is purged to disk rather than to 
magnetic tape. Unpurging, however, is via a BCD-to-ASCII translation and then 
via the offline Multics I/O daemon to a printer or card punch. 


A virtual machine, corresponding to the GCOS environment comprises: 


e One central processor 
256K of memory (one Multics segment) 


e One Input/Output Multiplexor (I0OM) with magnetic tape and disk subsystems, 
but with no unit record devices 


& One Front-End Network Processor (FNP) with one remote terminal (the 
interactive user's terminal for Multics, and the direct-access 
output-then-input terminal for GCOS -- this terminal also receives 


GCOS console output messages). 
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nH fF B& fF FR Boca _ 


fr fF FF BG LF 


$ 


see exclamation point 
ENDJOB 2-13, 2-15 
EXECUTE 2-13 
FILE 2-13 
FORTRAN 3-10 
GMAP 3-10 


IDENT 122; 


1-15, 
An-2, A-5 


22407 2213. AS: 


LIMITS 2<11 

MSG3 1-16 

PARAM 3-4 

PRINT... P#* 2-7 

PRMFL 1-4, 1-11, 1-15, 2-3, 2-9, 
2-14 

SELECT 4-404 
Dag, 2 


SNUMB 1-16, 2-10, A-2 


USERID 1-2, 1-5 


*ABT message 2-14 


*EOJ message 2-13 


.~MGENB module C-2 


abbreviations 


absin (absentee input) 

ACL (aecess control list) 

ALM (Assembly Language for Multics) 

also see GCOS access modes 

also see Multics access modes 

BCW (block control word) 

BMC (bulk media conversion) 

COMDK (compressed source deck) 

FIB (file information block) 

FMS (file management supervisor) 

ge (geos command 

gebl (geos build library command) 

geem (gcos extract module command) 

gef (geos Create file command) 

gels (geos library summary command) 

gelt (geos label tape command) 

GCOS (General Comprehensive 
Operating Supervisor) 

gept (geos pull _tapefile command) 
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INDEX 


batch (cont.) 


gers (geos reformat _syslib command) 

gcu (geos Card_utility command) 

gdd (geos directory directory) 

gfms (gcos fms command) 

gse (gcos Set_environment command) 

gsp Ske aR command) 

gspn (gcos syspunch command) 

gtbl (geos_tss_ build library 
command )~ - 

GTSS (GCOS time sharing environment 
simulator) 

gtss (geos tss command) 

Ic (Instruction Counter) 

IMCV (input media conversion) 

IOS (input/output supervisor) 

IR (Indicator Register) 

(master mode entry) 

(peripheral assignment table) 

(record control word) 

(system master catalog) 

(standard system format) 

udd (user directory directory) 

UFAS (unified file aecess system) 

UMC (user master catalog) 


absentee 


file A-2 
job 1-1, 1-4 
scheduling 1-16 
process 
see process 
processing 1-1 
queue A-2 


absin 


absolute pathname 1-10, 


also see abbreviations 
file 
see file 


1-11, 3-8 


absout 


REL 125, 


also see abbreviations 
file 
see file 


1-15, 1-16, A-7 
also see abbreviations 


allocator 2-1 


ALM 


see abbreviations 


Anonymous.GCOS.g 1-15 


backspace 2-9 
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BCD-to-ASCII translation 2-9 


BCW 
see abbreviations 

BMC 
see abbreviations 

building geos and library files B-12 

eanonicalization 2-9 

eard image 3-4 


catalog 
name 
see names 
permission 1-5 


COMDK 
see abbreviations 
command level reset 3-5 


commands 
daemon A-3 
gceos 1-2, 2-6, 2-7, 2-8, 2-10, 2-12, 
, 
geos build library B-2 
gcos card utility 2-8, 
geos create file 3-18 
geos extract module B-4 
gcos fms 3-19 
gceos label tape 3-21 
gcos library summary B-5 
geos pull ees B=-6 
gcos reformat syslib B 
geos set environment 1 
geos sysprint 3-24 
gceos syspunch 3-25 
geos tss 1-3, 1-14, 6-1 
geos tss build library B-10 
geos userg$add A-5 
geos user$delete A-6 
gcos user$init table A-5 
gcos_user$print A-6 


bya 


“9 
=35 (3=22 


console 
see user 


control card 
differences 5-2 
dollar 5-1 
non-GCOS dollar 5-1 
nondollar 5-1 
processing 5-1 


copying partial 3-13 
daemon commands A-3 


data format 2-5, 2-8 
derail faults 
see fault 


derail processing 7-1 


directory 
name 
see names 
process (pdir) 2-5 
structure A-2 
SYSOUT (syot_dir) 2-5 
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directory (cont.) 
temporary (temp dir) 2-5 
working (wdir) 2-5 


dollar cards 2-8 
DRL handler 1-3 
aditing convention 6-3 


entry names 
see names 


entrynane 
see names 


escape character convention 6-4 
exclamation point iii 
execution report 2-15 


fault 
derail 2-13, 7-1 
processing 7-1 
restrictions 2-13 


fault handler 2-1 


FIB 2-5 

also see abbreviations 
file 1-1, 1-4, 2-3 
#¥ D2 
absent 1-1 


sentee input (absin) a 


absentee output (absout) 


code designators 2- 
content (1/0) 3-11 
eonversion (print) 
eonversion (punch 
converted copies 
copy 3-7 
create 1- 
delete 1- 
format 2- 
format (I 
H #* 1-3 
I/O lists 3-1 
input 2-6 
restriction 3-3 
Lae 2-2, 2410 
name 
see names 
organization 2-5 
output 2-6, A-2 
name duplication 3-14 
Pp¥X OL 
pernfiles 2-15 
permission 1-5 
placement of 2-6 
R¥*¥ 2-10 


) 
ee 


softw-syslib 
reformat B~9 
sysprint 2-6, 
syspunch 2-6, 
system 1-4 
access modes 1-6 
differences 1-10 
naming convention 1-4 
restrictions 1-4 
system tape 
extract modules B-4 
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file (eont.) 
tape (1/0) 3-12 
user 2-4 


FMS 
see adbreviations 
functions 5 
allocation 2-10 
peripherals 2-11 
derail 6-1 
execution 2-12 
fault processing 2-12 
operating system C-1 
termination 2-13 
abnormal 2-14 
normal 2-13 


GCOS 
a ministrator -1 
a see ey a ations 


daemon 1-4, 3-2, A-1, 
composition A~1 
installing A-6 
restrictions 1-15 

differences C-1 

directory 
create A-7 

environment simulator 
invoking 3-2 
features 
not simulated 1-3 

file system 1-4 

FMS 3-19 

permissions 
abbreviations 1-6 

pool 2-4 

Sys Daemon 
registering A-6 
structure A-7 

system tape 
read file B-6 

user error subroutine 2-12 

user table 
adding to A-5 
creating A-5 
deleting from A-6 
examining contents A-6 
initializing A-5 
maintenance of A-5 


A-5, 


GCOS file attributes 1-14 
ec 1-14 


GCOS time sharing 
simulator 
see time share 


geos_ directory directory 
create A-7 


gdd 
see abbreviations 


GTSS 
see abbreviations 
software files 6-1 
terminal interface 6-2 
differences 6-3 


hardcore supervisor 2-1 
E79 
flow A-2 


operation 2-3 
specifications 3-8 
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IC 2-13, 2-14 
also see abbreviations 


IMCV 1-4 
also see abbreviations 
tapes 2-8 


input reader 2-1 


interactive process 
see process 


Ios 
see abbreviations 


IR 
see abbreviations 


job 
deck 2-7 
entered offline C-2 
input 2-7 
limits 2-10 
output 2-15 
priorities A-2 
rejection 3-3 


L*¥ 
see library 


library 
catalog B-2 
eonstruction 2-2 
GELOAD B-9 
print catalog B-5 
search rules 2-2 
software 2-2 
subroutine (L*®) 2-2 
system 2-2 


mappsue 1-12, 1- 
le strings b 


nent IAn 4 
permission 1 


rules 1-12 


MME 
-EMM 1-2 
abort lock 1-7 
also see abbreviations 
differences 4-1 


GEBORT 2-12, 2-14, 2-15 
GECALL 2-1, p=? 

GEFINI 2-2’ 

GEFSYE 1-4, 1-11 

GEINOS 2-3, 2-5 

GEMORE 2-5 

GEROAD 2-3 

GESAVE 2-2 

GESNAP 2-15 

GESTR 2-2 

GESYOT 2-6 

mandier i-3, 2-1 
processing 1-2, 2-7, 4-1 


routines 2-12 
security lock 1-7 
simulator 2-1 


Multics 
access modes 
abbreviations 1-6 
facilities 1-3 
file system 1-4 
page 2-5 
process C-1 
ring protection mechanism 1-15 
segment 1-4 
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Multies (cont.) 
storage system 2-4 
subsystem C-1 

names 
catalog 1-4 
directory 1-4 
entry 1-4, 2-6 
entr yname 

restrictions 1-5 
file 1-4, 2-5 

alternate name 1-5 

restriction 3-4 
unique 3-4 

nondollar cards 2-8 

nonfatal error 2-19 

operator interface A-3 


PAT 2-5 
also see abbreviations 


pdir 
see directory 


person identificaton 
Anonymous 1-15 


personid 1-2 
postmortem memory dump 2-14 
process i-1 
absentee 1-1 
daemon 1-1 
end-of-job 2-15 
identification 2-10 
interactive 1-1 
user 1-2 
projectid i-2 
pseudoperipherals 2-11 
quota 2-5, 2-6 


RCW 
see abbreviations 


record quota overflow A-5 
relative pathname 1-10, 3-8 
resource usage limits 2-10 
ring brackets 1-15 

runtime parameters 3-22 
segment 1-4, A-2 


simulator 
environment 
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simulator (cont.) 
GCOS Time Sharing 6-1 
file creation 3-4 
file use 3-4 
input 3-2 
output 3-3 
security problem 1-5 


Slave area 2-2 


SMC 
see abbreviations 


software library 
see library 


SSF 
see abbreviations 


subdirectories 


t —_ 


subroutine library 
see library 


syot_dir 
see directory 


tab replacement 2-9 
tabstops 2-9, 3-19 


temp dir 
see directory 


time share 
simulator 1-1, 1-3 
functions 1-3 


transmission convention 6-3 


udd 
see abbreviations 


UFAS 
see abbreviations 


UMC 
see abbreviations 


unrecoverable errors 3-5 


user 
console 1-2 
interface A-1 
program interface 6-5 
Sign on 6-3 
terminal output 3-15 
utility commands 3-1 


variable parameters 2-10 
virtual machine C-2 


wdir 
see directory 
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